Skip to content

Commit

Permalink
finish private key , public key and pubkeyHash
Browse files Browse the repository at this point in the history
  • Loading branch information
KaKeimei committed Jun 27, 2024
1 parent 7b5a733 commit 0fe174b
Show file tree
Hide file tree
Showing 10 changed files with 185 additions and 20 deletions.
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,26 @@ sidebar_position: 1
---

# 私钥

介绍什么是私钥,如何生成。

## 公钥私钥简介

比特币和MVC使用密钥系统来控制所有权。其中最重要的是私钥和公钥。

[公钥](public-key.md)用于生成地址和锁定[UTXO](../transaction/utxo.md),表示接收方的身份。

私钥则用于计算和生成[签名](signature.md),证明所有权以及解锁UTXO。

如图所示,简单理解的话,公钥用来锁定UTXO,私钥用来解锁UTXO。

![img.png](/img/bitcoin-keys.png)

公钥和私钥是一对一的关系,私钥可以计算出公钥,但是公钥无法反推私钥。如果没有对应的私钥,无法生成有效的[签名](signature.md)
,也就无法解锁UTXO。但是验证签名不需要使用私钥,可以仅通过公钥和签名来验证。

## 私钥结构

私钥是一个随机数,通常是一个256位的随机数,可以用各种方式生成,比如随机数生成器、硬件随机数等。最原始也最安全的私钥生成方法就是扔硬币,正面是0,反面计作1,连续抛256次,得到的01序列就是私钥。

私钥通常使用[WIF格式](wif.md)(Wallet Import Format)进行编码,方便记录和保存,也可以直接使用16进制的格式进行记录。
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,67 @@ sidebar_position: 3
---

# 公钥哈希

介绍公钥哈希,以及它与地址的关系。

## 公钥哈希简介

公钥哈希故名思义,是公钥的[哈希值](../../../mining/concepts/hash-algorithm.md)。在比特币中,公钥哈希是一种常用的地址表示方式,用于接收比特币。

将公钥进行哈希处理一方面是为了将公钥长度固定化,另一方面是为了保护公钥的安全性。公钥哈希是一个固定长度的字符串,通常是160位,可以用各种方式表示,比如Base58编码、Base64编码等。

公钥哈希是比特币地址的核心部分,它是一种经过多次哈希运算生成的短小且安全的表示方式。公钥哈希用来避免直接暴露公钥,增加安全性和隐私性。比特币地址实际上是公钥哈希再经过一些编码步骤处理后的结果。
## Hash160

公钥哈希的计算过程通常是先对公钥进行哈希,再对哈希值进行二次哈希。这种计算方式叫做Hash160,是比特币中常用的哈希算法。


### 从公钥计算公钥哈希

计算公钥哈希的过程包括以下几个步骤:

1. **计算 SHA-256 哈希**:首先对公钥进行 SHA-256 哈希运算,得到一个 256 位的哈希值。
2. **计算 RIPEMD-160 哈希**:然后对 SHA-256 的输出结果进行 RIPEMD-160 哈希运算,得到一个 160 位的哈希值。

这个过程通常称为 Hash160,因为它结合了两种不同的哈希函数。

### 详细介绍 Hash160 过程

假设公钥表示为 \( K \),计算 Hash160 的具体步骤如下:

1. **计算 SHA-256 哈希**
$$ H_1 = \text{SHA-256}(K) $$

2. **计算 RIPEMD-160 哈希**
$$ H_{160} = \text{RIPEMD-160}(H_1) $$

### Hash160 过程的公式

使用 KaTeX 表示:

1. 计算 SHA-256 哈希:
$$ H_1 = \text{SHA-256}(K) $$

2. 计算 RIPEMD-160 哈希:
$$ H_{160} = \text{RIPEMD-160}(H_1) $$

### 举例说明

假设公钥 \( K \) 为:
\[ K = 04b0bd634234abbb1ba1e986e8841855dd45b2a4f7cd9b4c8e0ec6ccf97c71548520b2a6d03cfcc92d5a4a3ac2e4ab7c1b3b9d0b4d43fb2314cd2fce6b81f8d2a \]

步骤如下:

1. 计算 SHA-256 哈希:
$$ H_1 = \text{SHA-256}\left(04b0bd634234abbb1ba1e986e8841855dd45b2a4f7cd9b4c8e0ec6ccf97c71548520b2a6d03cfcc92d5a4a3ac2e4ab7c1b3b9d0b4d43fb2314cd2fce6b81f8d2a\right) $$
假设结果为:
$$ H_1 = 0x68c1f88b3a3f3e52c7f9bcb15708fbbb5b4083a12c67d32d25fbb3a1de0b6e8e $$

2. 计算 RIPEMD-160 哈希:
$$ H_{160} = \text{RIPEMD-160}\left(0x68c1f88b3a3f3e52c7f9bcb15708fbbb5b4083a12c67d32d25fbb3a1de0b6e8e\right) $$
假设结果为:
$$ H_{160} = 0xb2f37a2391e02b1b01a70c8d6c027d0f431cbdc6 $$

这个 160 位的哈希值 \( H_{160} \) 就是公钥哈希。

通过这个过程,公钥被转换为一个更短的哈希值,便于存储和使用,并提高了安全性。
Original file line number Diff line number Diff line change
Expand Up @@ -3,3 +3,59 @@ sidebar_position: 2
---

# 公钥

介绍什么是公钥,如何生成和表示公钥。

## 公钥简介

公钥的本质是椭圆曲线上的一组坐标值,这个坐标可以通过[私钥](private-key.md)计算出来。

## 椭圆曲线

椭圆曲线是密码学系统所使用的一种曲线。可以使用点乘运算来进行加密和解密。椭圆曲线的一个特点是,两个点相加后仍然在曲线上,这样就可以通过多次相加来实现加密。

![img.png](/img/bitcoin-elliptic-curve.png)

### 椭圆曲线的定义

椭圆曲线通常表示为一个方程,形如:
$$ y^2 = x^3 + ax + b $$
对于 secp256k1,方程的具体形式为:
$$ y^2 = x^3 + 7 $$
\(a = 0\)\(b = 7\)

比特币使用的椭圆曲线是一种用于密码学的数学结构。具体来说,比特币使用的是椭圆曲线 secp256k1,这是一种定义在有限域上的椭圆曲线,常用于公钥加密。

## 如何计算公钥

### 从私钥计算公钥

1. **选择基点(G)**:椭圆曲线 secp256k1 定义了一个基点 \( G \),这是一个固定的点,具有特定的坐标。
2. **计算公钥**:使用私钥(\( k \))和基点(\( G \)),通过椭圆曲线上的点乘运算计算出公钥(\( K \))。这个过程类似于标量乘法:
$$ K = k \cdot G $$
这里,\( k \) 是私钥,\( G \) 是基点,\( K \) 是公钥。

### 点乘运算

点乘运算不是普通的乘法,而是通过一系列椭圆曲线上的点加法和倍加来实现的。简要步骤如下:

1. **点加法(Point Addition)**:如果有两个点 \( P = (x_1, y_1) \)\( Q = (x_2, y_2) \),那么它们的和 \( R = (x_3, y_3) \) 的计算方式如下:
- 计算斜率 \( m \)
$$ m = \frac{y_2 - y_1}{x_2 - x_1} $$
- 计算新点的坐标:
$$ x_3 = m^2 - x_1 - x_2 $$
$$ y_3 = m(x_1 - x_3) - y_1 $$

2. **点倍加(Point Doubling)**:当 \( P = Q \) 时,计算方式类似,但斜率公式不同:
- 计算斜率 \( m \)
$$ m = \frac{3x_1^2 + a}{2y_1} $$
- 计算新点的坐标:
$$ x_3 = m^2 - 2x_1 $$
$$ y_3 = m(x_1 - x_3) - y_1 $$

通过不断应用点加法和点倍加操作,能将基点 \( G \) 变为公钥 \( K \)

## 椭圆曲线加密的安全性

椭圆曲线加密的安全性依赖于椭圆曲线离散对数问题(ECDLP)的难度。即从公钥 \( K \) 推算私钥 \( k \) 是非常困难的,确保了加密的安全性。

Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
---
sidebar_position: 3
---

# Token溯源问题

介绍什么是Token溯源问题以及为什么需要溯源。
Expand All @@ -9,9 +10,11 @@ sidebar_position: 3

我们举一个实际的例子:

FT,也就是Fungible Token同质化代币合约,是一种标准的代币合约。与以太坊的全局合约账本状态不同的是,在MVC中,它的合约状态是一个个UTXO,这些FT UTXO的状态包括代币的代号,创始信息,代币数量,所有权等多个信息。合约需要让有FT所有权的人可以解锁,而没有控制权(私钥)的人无法解锁并转账FT。控制权的问题很好解决,只要在合约中要求状态转移函数携带所有者的签名,并且签名正确才可以转移所有权。
FT,也就是Fungible Token同质化代币合约,是一种标准的代币合约。与以太坊的全局合约账本状态不同的是,在MVC中,它的合约状态是一个个UTXO,这些FT
UTXO的状态包括代币的代号,创始信息,代币数量,所有权等多个信息。合约需要让有FT所有权的人可以解锁,而没有控制权(私钥)的人无法解锁并转账FT。控制权的问题很好解决,只要在合约中要求状态转移函数携带所有者的签名,并且签名正确才可以转移所有权。

但是有另一个问题仅仅通过所有权校验无法被解决,那就是token真实性的问题。由于UTXO自身是无状态的,它无法感知到自身之外的信息,除非将外部信息作为参数传递给函数。另外由于UTXO函数的代码和状态数据都是链上公开的,任何人都可以伪造一个一模一样的UTXO,这个UTXO的状态和代码都是正确的,但是它并不是真正的FT UTXO,如果允许这样的行为,那么意味着FT将会被任意超发,发行者和持有者将会受到重大损失。
但是有另一个问题仅仅通过所有权校验无法被解决,那就是token真实性的问题。由于UTXO自身是无状态的,它无法感知到自身之外的信息,除非将外部信息作为参数传递给函数。另外由于UTXO函数的代码和状态数据都是链上公开的,任何人都可以伪造一个一模一样的UTXO,这个UTXO的状态和代码都是正确的,但是它并不是真正的FT
UTXO,如果允许这样的行为,那么意味着FT将会被任意超发,发行者和持有者将会受到重大损失。

在UTXO合约中理论上当然可以解决这样的问题,编写FT合约的时候,我们强制要求参数中携带当前FT的所有祖先交易信息(无论通过递归方式还是通过循环方式),然后逐一校验祖先交易的合法性,一直追溯到创始交易,能够完整形成溯源证据链条的才被当作合法交易。而刚才伪造的交易一定无法构建溯源证据链条。

Expand All @@ -21,5 +24,6 @@ FT,也就是Fungible Token同质化代币合约,是一种标准的代币合

在一些竞争链解决方案中,token正确性一般通过两种方式来解决,一种是indexer共识,在一层utxo状态外再建立一套indexer机制,由indexer负责校验utxo是否合法,这是一种二层方案。二层方案最大的弊端就是无法保证和主链的一致性,比如说,brc20依赖indexer,你可以意外把brc20token当作普通satoshi花费掉,还有一些场景,layer1可以解锁的合约在indexer上并不合法,也就是说,共识不仅仅是layer1来保证,而是通过layer1和indexer共同保证,出bug和问题的可能性大大增加。另一种解决方法是使用oracle,这是一种利用外部可信数据源来保证token正确性的方案,但是oracle的问题是,它依赖于外部数据源,一旦外部数据源出现问题,那么token的正确性也会受到影响(oracle作恶问题)。

MVC使用了一种称为[MetaTxid](meta-txid.md)的技术,可以在不引起交易膨胀的前提下,实现纯一层合约的溯源功能,不再依赖外部indexer和oracle来维护状态正确性,而是仅仅通过utxo本身以及部分前序交易就可以鉴别token合法性,也就是说token是否合法的信息,已经全部包含在合约内部了,不需要区块链外部状态辅助判断(这是layer1的一个重要特征)。
MVC使用了一种称为[MetaTxid](meta-txid.md)
的技术,可以在不引起交易膨胀的前提下,实现纯一层合约的溯源功能,不再依赖外部indexer和oracle来维护状态正确性,而是仅仅通过utxo本身以及部分前序交易就可以鉴别token合法性,也就是说token是否合法的信息,已经全部包含在合约内部了,不需要区块链外部状态辅助判断(这是layer1的一个重要特征)。

Original file line number Diff line number Diff line change
Expand Up @@ -42,7 +42,6 @@ BVM是基于比特币的[脚本系统](https://en.bitcoin.it/wiki/Script)
4. BVM的合约计算的结果只包含TRUE或者FALSE,通过UTXO是否能够被解锁来判断合约是否执行成功。
5. BVM的合约具备原子性,要么全部成功,要么全部失败,不会出现部分执行的情况。校验失败的合约不会消耗GAS费,因为会被看作非法交易,不会记录上链。


## 操作码解锁

比特币设计的时候出于安全考虑,限制了可以使用的操作码数量和类型,只允许几大标准类型的交易输出,导致智能合约的功能受到限制。
Expand Down
Original file line number Diff line number Diff line change
@@ -1,6 +1,7 @@
---
sidebar_position: 6
---

# MetaContract

介绍MetaContract标准合约。
Expand All @@ -9,21 +10,22 @@ sidebar_position: 6

## FT(Fungible Token)合约

FT合约是一种标准的代币合约。与以太坊的全局合约账本状态不同的是,在MVC中,它的合约状态是一个个UTXO,这些FT UTXO的状态包括代币的代号,创始信息,代币数量,所有权等多个信息。合约需要让有FT所有权的人可以解锁,而没有控制权(私钥)的人无法解锁并转账FT。只要在合约中要求状态转移函数携带所有者的签名,并且签名正确才可以转移所有权。
FT合约是一种标准的代币合约。与以太坊的全局合约账本状态不同的是,在MVC中,它的合约状态是一个个UTXO,这些FT
UTXO的状态包括代币的代号,创始信息,代币数量,所有权等多个信息。合约需要让有FT所有权的人可以解锁,而没有控制权(私钥)的人无法解锁并转账FT。只要在合约中要求状态转移函数携带所有者的签名,并且签名正确才可以转移所有权。

合约详情解析请参考[FT合约](../../contract/mvc-standard/ft-token.md)

源码仓库:https://github.com/mvc-labs/token-core

## NFT(Non-Fungible Token)合约

NFT合约是一种标准的非同质化代币合约。NFT合约的合约状态是一个个UTXO,这些NFT UTXO的状态包括代币的代号,创始信息,代币数量,所有权等多个信息。合约需要让有NFT所有权的人可以解锁,而没有控制权(私钥)的人无法解锁并转账NFT。只要在合约中要求状态转移函数携带所有者的签名,并且签名正确才可以转移所有权。
NFT合约是一种标准的非同质化代币合约。NFT合约的合约状态是一个个UTXO,这些NFT
UTXO的状态包括代币的代号,创始信息,代币数量,所有权等多个信息。合约需要让有NFT所有权的人可以解锁,而没有控制权(私钥)的人无法解锁并转账NFT。只要在合约中要求状态转移函数携带所有者的签名,并且签名正确才可以转移所有权。

合约详情解析请参考[NFT合约](../../contract/mvc-standard/nft-token.md)

源码仓库:https://github.com/mvc-labs/nft-core


## DAO(Decentralized Autonomous Organization)合约

DAO合约是一种标准的去中心化自治组织合约。DAO合约用于MVCDAO的投票和治理,需要质押足够的SPACE代币才可以对提案进行投票。
Expand Down
Original file line number Diff line number Diff line change
@@ -1,19 +1,23 @@
---
sidebar_position: 5
---

# MetaId

介绍MetaId身份协议。

[MetaID](https://docs.metaid.io/) 是一个构建在比特币及其同构区块链(MVC等)上的统一身份和数据格式协议。基于 MetaID 协议,开发者可以在比特币上构建各种数据互联互通,数据归用户所有的 Web3 应用。
[MetaID](https://docs.metaid.io/) 是一个构建在比特币及其同构区块链(MVC等)上的统一身份和数据格式协议。基于 MetaID
协议,开发者可以在比特币上构建各种数据互联互通,数据归用户所有的 Web3 应用。

## MetaID的用途

简单来说,MetaID 可以用于
在比特币和MVC上构建所有类型的 Web3 应用,包括社交类应用、游戏、电商应用等。

在比特币和MVC上发行和数据价值紧密结合的各种 FT 和 NFT 资产。

## MetaID 特点

将离散的区块链数据抽象成有序的树状结构数据,为在比特币上构建 Web3 应用而准备;

用户信息和应用数据全部上链,保存在由用户控制的私钥所对应的地址上,做到用户数据和其他方无关,数据归属权彻底由数据产生者所有;
Expand All @@ -23,12 +27,17 @@ sidebar_position: 5
不同应用间的数据可以相互连通,消除应用间数据孤岛;不同协议数据可以在用户的 MetaID 关联下相互组合,Web3 应用开发工作大为减少。

## MetaID 愿景

比特币由于具有高共识、高并发以及支持数据在本链保存等特性,是成为 Web3 应用的最好载体,MetaID 目标是成为比特币生态上最大的用户身份和数据统一协议;

MetaID 将打造一个数据互联互通、数据归属用户、用户数据和资产天然结合的新的 Web3 开发范式,我们相信 Bitcoin = Money + Data。

## MetaID 基本原理
通过 MetaID 协议,将散落在区块链上的基于 MetaID 的交易,以“人”为分类方式,将数据以树状结构进行完全分类。在 MetaID 协议的视角下,所有链上数据均抽象成“MetaID 树”的格式在链上进行保存,链上数据从此只有一棵棵“MetaID 树”,因此可以做到数据和链无关,甚至和保存数据的信封格式无关,只要最终实现的“MetaID 树”符合 MetaID 格式,便可以实现数据归属用户、数据有序存放和数据互联互通等特性。因此在这基础上可以构建一切形式的 Web3 应用。

通过 MetaID 协议,将散落在区块链上的基于 MetaID 的交易,以“人”为分类方式,将数据以树状结构进行完全分类。在 MetaID
协议的视角下,所有链上数据均抽象成“MetaID 树”的格式在链上进行保存,链上数据从此只有一棵棵“MetaID
树”,因此可以做到数据和链无关,甚至和保存数据的信封格式无关,只要最终实现的“MetaID 树”符合 MetaID
格式,便可以实现数据归属用户、数据有序存放和数据互联互通等特性。因此在这基础上可以构建一切形式的 Web3 应用。

以“人”为分类方式,将离散的区块链数据变成有序的结构数据;
![img.png](/img/metaid-structure.png)
Expand Down
Loading

0 comments on commit 0fe174b

Please sign in to comment.