From dfd0a649c783c2a5dee56ac2a5b539f4505a017d Mon Sep 17 00:00:00 2001 From: Paouky <8108020+Paouky@users.noreply.github.com> Date: Thu, 10 Sep 2020 16:45:14 +0300 Subject: [PATCH] Organize doc files (#3436) * create and occupy translations dir * update translation links * add mimblewimble whitepaper * add p2p_protocol from docs * add validation_logic from docs Co-authored-by: Paouky --- doc/build.md | 4 +- doc/code_structure.md | 2 +- doc/coinbase_maturity.md | 2 +- doc/contracts.md | 2 +- doc/fast-sync.md | 2 +- doc/grin4bitcoiners.md | 2 +- doc/intro.md | 24 +- doc/merkle.md | 4 +- doc/mmr.md | 4 +- doc/p2p/p2p_protocol.md | 277 ++++++++++++++++++ doc/pruning.md | 2 +- doc/state.md | 2 +- doc/stratum.md | 58 ++-- doc/switch_commitment.md | 14 +- doc/table_of_contents.md | 2 +- doc/{ => translations}/build_ES.md | 2 +- doc/{ => translations}/build_JP.md | 2 +- doc/{ => translations}/build_KR.md | 2 +- doc/{ => translations}/build_ZH-CN.md | 2 +- .../code_structure_ZH-CN.md | 2 +- .../coinbase_maturity_KR.md | 0 .../coinbase_maturity_ZH-CN.md | 4 +- .../contract_ideas_ZH-CN.md | 0 doc/{ => translations}/contracts_ZH-CN.md | 0 doc/{ => translations}/fast-sync_ES.md | 14 +- doc/{ => translations}/fast-sync_KR.md | 2 +- doc/{ => translations}/fast-sync_ZH-CN.md | 2 +- doc/{ => translations}/grin4bitcoiners_KR.md | 0 .../grin4bitcoiners_ZH-CN.md | 2 +- doc/{ => translations}/intro_DE.md | 22 +- doc/{ => translations}/intro_ES.md | 204 ++++++------- doc/{ => translations}/intro_JP.md | 8 +- doc/{ => translations}/intro_KR.md | 48 +-- doc/{ => translations}/intro_NL.md | 16 +- doc/{ => translations}/intro_PT-BR.md | 3 +- doc/{ => translations}/intro_RU.md | 54 ++-- doc/{ => translations}/intro_SE.md | 74 ++--- doc/{ => translations}/intro_ZH-CN.md | 14 +- doc/{ => translations}/merkle_KR.md | 0 doc/{ => translations}/merkle_ZH-CN.md | 2 +- doc/translations/mimblewimble.md | 263 +++++++++++++++++ doc/{ => translations}/mmr_KR.md | 8 +- doc/{ => translations}/mmr_ZH-CN.md | 4 +- doc/{ => translations}/pruning_KR.md | 0 doc/{ => translations}/pruning_ZH-CN.md | 4 +- doc/{ => translations}/state_JP.md | 2 +- doc/{ => translations}/state_KR.md | 4 +- doc/{ => translations}/state_ZH-CN.md | 2 +- doc/{ => translations}/stratum_KR.md | 0 doc/{ => translations}/stratum_ZH-CN.md | 58 ++-- .../switch_commitment_ZH-CN.md | 10 +- .../table_of_contents_KR.md | 0 .../table_of_contents_ZH-CN.md | 2 +- doc/validation/validation_logic.md | 48 +++ 54 files changed, 936 insertions(+), 349 deletions(-) create mode 100644 doc/p2p/p2p_protocol.md rename doc/{ => translations}/build_ES.md (97%) rename doc/{ => translations}/build_JP.md (97%) rename doc/{ => translations}/build_KR.md (98%) rename doc/{ => translations}/build_ZH-CN.md (97%) rename doc/{ => translations}/code_structure_ZH-CN.md (98%) rename doc/{ => translations}/coinbase_maturity_KR.md (100%) rename doc/{ => translations}/coinbase_maturity_ZH-CN.md (97%) rename doc/{ => translations}/contract_ideas_ZH-CN.md (100%) rename doc/{ => translations}/contracts_ZH-CN.md (100%) rename doc/{ => translations}/fast-sync_ES.md (67%) rename doc/{ => translations}/fast-sync_KR.md (95%) rename doc/{ => translations}/fast-sync_ZH-CN.md (90%) rename doc/{ => translations}/grin4bitcoiners_KR.md (100%) rename doc/{ => translations}/grin4bitcoiners_ZH-CN.md (97%) rename doc/{ => translations}/intro_DE.md (97%) rename doc/{ => translations}/intro_ES.md (75%) rename doc/{ => translations}/intro_JP.md (98%) rename doc/{ => translations}/intro_KR.md (96%) rename doc/{ => translations}/intro_NL.md (98%) rename doc/{ => translations}/intro_PT-BR.md (98%) rename doc/{ => translations}/intro_RU.md (97%) rename doc/{ => translations}/intro_SE.md (96%) rename doc/{ => translations}/intro_ZH-CN.md (98%) rename doc/{ => translations}/merkle_KR.md (100%) rename doc/{ => translations}/merkle_ZH-CN.md (98%) create mode 100644 doc/translations/mimblewimble.md rename doc/{ => translations}/mmr_KR.md (97%) rename doc/{ => translations}/mmr_ZH-CN.md (98%) rename doc/{ => translations}/pruning_KR.md (100%) rename doc/{ => translations}/pruning_ZH-CN.md (97%) rename doc/{ => translations}/state_JP.md (97%) rename doc/{ => translations}/state_KR.md (97%) rename doc/{ => translations}/state_ZH-CN.md (96%) rename doc/{ => translations}/stratum_KR.md (100%) rename doc/{ => translations}/stratum_ZH-CN.md (97%) rename doc/{ => translations}/switch_commitment_ZH-CN.md (98%) rename doc/{ => translations}/table_of_contents_KR.md (100%) rename doc/{ => translations}/table_of_contents_ZH-CN.md (94%) create mode 100644 doc/validation/validation_logic.md diff --git a/doc/build.md b/doc/build.md index 543376b798..011e925ee4 100644 --- a/doc/build.md +++ b/doc/build.md @@ -1,6 +1,6 @@ # Grin - Build, Configuration, and Running -*Read this in other languages: [Español](build_ES.md), [Korean](build_KR.md), [日本語](build_JP.md), [简体中文](build_ZH-CN.md).* +*Read this in other languages: [Español](translations/build_ES.md), [Korean](translations/build_KR.md), [日本語](translations/build_JP.md), [简体中文](translations/build_ZH-CN.md).* ## Supported Platforms @@ -138,4 +138,4 @@ Please note that all mining functions for Grin have moved into a separate, stand you can start mining by building and running grin-miner against your running Grin node. For grin-miner to be able to communicate with your grin node, make sure that you have `enable_stratum_server = true` -in your `grin-server.toml` configuration file and you have a wallet listener running (`grin-wallet listen`). +in your `grin-server.toml` configuration file and you have a wallet listener running (`grin-wallet listen`). diff --git a/doc/code_structure.md b/doc/code_structure.md index e14c3e9f79..8ab62e9968 100644 --- a/doc/code_structure.md +++ b/doc/code_structure.md @@ -1,6 +1,6 @@ # Grin code structure -*Read this in other languages: [简体中文](code_structure_ZH-CN.md).* +*Read this in other languages: [简体中文](translations/code_structure_ZH-CN.md).* Grin is built in [Rust](https://www.rust-lang.org/), a memory safe, compiled language. Performance critical parts like the Cuckoo mining algorithm are built as plugins, making it easy to swap between algorithm implementations for various hardware. Grin comes with CPU and experimental GPU support. diff --git a/doc/coinbase_maturity.md b/doc/coinbase_maturity.md index 728b8e42e5..24ad7d881c 100644 --- a/doc/coinbase_maturity.md +++ b/doc/coinbase_maturity.md @@ -1,6 +1,6 @@ # The Coinbase Maturity Rule (aka Output Lock Heights) -*Read this in other languages: [Korean](coinbase_maturity_KR.md), [简体中文](coinbase_maturity_ZH-CN).* +*Read this in other languages: [Korean](translations/coinbase_maturity_KR.md), [简体中文](translations/coinbase_maturity_ZH-CN).* Coinbase outputs (block rewards & fees) are "locked" and require 1,440 confirmations (i.e 24 hours worth of blocks added to the chain) before they mature sufficiently to be spendable. This is to reduce the risk of later txs being reversed if a chain reorganization occurs. diff --git a/doc/contracts.md b/doc/contracts.md index 751c02b6f1..e6c4bdccbd 100644 --- a/doc/contracts.md +++ b/doc/contracts.md @@ -1,6 +1,6 @@ # Contracts -*Read this in other languages: [简体中文]( contracts_ZH-CN.md)* +*Read this in other languages: [简体中文](translations/contracts_ZH-CN.md)* This document describes smart contracts that can be setup using Grin even though the Grin chain does not support scripting. All these contracts rely diff --git a/doc/fast-sync.md b/doc/fast-sync.md index 3358f75e2f..b1a693a601 100644 --- a/doc/fast-sync.md +++ b/doc/fast-sync.md @@ -1,6 +1,6 @@ # Fast Sync -*Read this in other languages: [Español](fast-sync_ES.md), [Korean](fast-sync_KR.md), [简体中文](fast-sync_ZH-CN.md).* +*Read this in other languages: [Español](translations/fast-sync_ES.md), [Korean](translations/fast-sync_KR.md), [简体中文](translations/fast-sync_ZH-CN.md).* In Grin, we call "sync" the process of synchronizing a new node or a node that hasn't been keeping up with the chain for a while, and bringing it up to the diff --git a/doc/grin4bitcoiners.md b/doc/grin4bitcoiners.md index a06f6d3bac..210c59a4e5 100644 --- a/doc/grin4bitcoiners.md +++ b/doc/grin4bitcoiners.md @@ -1,6 +1,6 @@ # Grin/Mimblewimble for Bitcoiners -*Read this in other languages:[Korean](grin4bitcoiners_KR.md) +*Read this in other languages:[Korean](translations/grin4bitcoiners_KR.md) ## Privacy and Fungibility diff --git a/doc/intro.md b/doc/intro.md index 0ee48a01b3..e98dad9442 100644 --- a/doc/intro.md +++ b/doc/intro.md @@ -1,6 +1,6 @@ # Introduction to Mimblewimble and Grin -*Read this in other languages: [English](intro.md), [简体中文](intro_ZH-CN.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* +*Read this in other languages: [简体中文](translations/intro_ZH-CN.md), [Español](translations/intro_ES.md), [Nederlands](translations/intro_NL.md), [Русский](translations/intro_RU.md), [日本語](translations/intro_JP.md), [Deutsch](translations/intro_DE.md), [Portuguese](translations/intro_PT-BR.md), [Korean](translations/intro_KR.md).* Mimblewimble is a blockchain format and protocol that provides extremely good scalability, privacy and fungibility by relying on strong @@ -23,7 +23,7 @@ The main goal and characteristics of the Grin project are: * Design simplicity that makes it easy to audit and maintain over time. * Community driven, encouraging mining decentralization. -A detailed post on the step-by-step of how Grin transactions work (with graphics) can be found [in this Medium post](https://medium.com/@brandonarvanaghi/grin-transactions-explained-step-by-step-fdceb905a853). +A detailed post on the step-by-step of how Grin transactions work (with graphics) can be found [in this Medium post](https://medium.com/@brandonarvanaghi/grin-transactions-explained-step-by-step-fdceb905a853). ## Tongue Tying for Everyone @@ -92,7 +92,7 @@ fundamental properties are achieved. Building upon the properties of ECC we described above, one can obscure the values in a transaction. -If _v_ is the value of a transaction input or output and _H_ a point on the elliptic curve _C_, we can simply +If _v_ is the value of a transaction input or output and _H_ a point on the elliptic curve _C_, we can simply embed `v*H` instead of _v_ in a transaction. This works because using the ECC operations, we can still validate that the sum of the outputs of a transaction equals the sum of inputs: @@ -144,8 +144,8 @@ transaction can be done without knowing any of the values. As a final note, this idea is actually derived from Greg Maxwell's [Confidential Transactions](https://elementsproject.org/features/confidential-transactions/investigation), -which is itself derived from an -[Adam Back proposal for homomorphic values](https://bitcointalk.org/index.php?topic=305791.0) +which is itself derived from an +[Adam Back proposal for homomorphic values](https://bitcointalk.org/index.php?topic=305791.0) applied to Bitcoin. #### Ownership @@ -249,7 +249,7 @@ by creating a transaction such as the following: which can be signed by the attacker because Carol's blinding factor cancels out in the equation `Y - Xi`: Y - Xi = ((113 + 99)*G + 2*H) - (113*G + 2*H) = 99*G - + This output (`(113 + 99)*G + 2*H`) requires that both the numbers 113 and 99 are known in order to be spent; the attacker would thus have successfully locked Carol's UTXO. The requirement for a range proof for the blinding factor prevents this because the attacker doesn't know the number 113 and thus neither (113 + 99). A more detailed description of range proofs is further detailed in the [range proof paper](https://eprint.iacr.org/2017/1066.pdf). @@ -260,7 +260,7 @@ A Mimblewimble transaction includes the following: * A set of inputs, that reference and spend a set of previous outputs. * A set of new outputs that include: - * A blinding factor *r* and a value *v* used for scalar multiplication for the curve + * A blinding factor *r* and a value *v* used for scalar multiplication for the curve points G,H correspondingly, and subsequently summed to be `r*G + v*H`. * A range proof that among other things shows that *v* is non-negative. * A transaction fee in cleartext. @@ -327,11 +327,11 @@ We also know that everything remaining can be used to reconstruct the other vali Remember that the kernel excess `r*G` simply is the public key of the excess value *r*. To mitigate this we redefine the kernel excess from `r*G` to `(r-kernel_offset)*G` and distribute the _kernel offset_ to be included with every transaction kernel. The kernel offset is thus a blinding factor that needs to be added to the excess value to ensure the commitments sum to zero: sum(outputs) - sum(inputs) = r*G = (r-kernel_offset)*G + kernel_offset*G - + or alternatively sum(outputs) - sum(inputs) = kernel_excess + kernel_offset*G - + For a commitment `r*G + 0*H` with the offset `a`, the transaction is signed with `(r-a)` and *a* is published so that `r*G` could be computed in order to verify the validity of the transaction: given the kernel excess (recall that it is given as part of the transaction kernel) `(r-a)*G` and the offset `a`, one computes `a*G` and obtains `(r-a)*G + a*G = r*G`. During block construction all kernel offsets are summed to generate a _single_ aggregate kernel offset to cover the whole block. The kernel offset for any individual transaction is then unrecoverable and the subset problem is solved. @@ -384,7 +384,7 @@ A block is simply built from: * The signatures generated using the (modified) excess value `(r-a)` as the private (signing) key. * The mining fee. -The block contents satisfy: +The block contents satisfy: sum(outputs) - sum(inputs) = sum(kernel_excess) + kernel_offset*G @@ -414,12 +414,12 @@ in time can be summarized by just these pieces of information: 1. The transactions kernels for each transaction. The first piece of information can be deduced just using the block -height. +height. Both the UTXOs and the transaction kernels are extremely compact. This has two important consequences: -* The blockchain a node needs to maintain is very small (on the +* The blockchain a node needs to maintain is very small (on the order of a few gigabytes for a bitcoin-sized blockchain, and potentially optimizable to a few hundreds of megabytes). * When a new node joins the network the amount of diff --git a/doc/merkle.md b/doc/merkle.md index 24e0e3e1a8..dff9dd1684 100644 --- a/doc/merkle.md +++ b/doc/merkle.md @@ -1,6 +1,6 @@ # Merkle Structures -*Read this in other languages: [Korean](merkle_KR.md), [简体中文](merkle_ZH-CN.md).* +*Read this in other languages: [Korean](translations/merkle_KR.md), [简体中文](translations/merkle_ZH-CN.md).* Mimblewimble is designed for users to verify the state of the system given only pruned data. To achieve this goal, all transaction data is committed @@ -66,7 +66,7 @@ The root sum should be equal to the sum of excesses for this block. See the next section. In general, validators will see either 100% of this Merkle tree or 0% of it, -so it is compatible with any design. +so it is compatible with any design. Design requirements: diff --git a/doc/mmr.md b/doc/mmr.md index 6f4cb763f5..c90848ef9f 100644 --- a/doc/mmr.md +++ b/doc/mmr.md @@ -1,6 +1,6 @@ # Merkle Mountain Ranges -*Read this in other languages: [Korean](mmr_KR.md), [简体中文](mmr_ZH-CN.md).* +*Read this in other languages: [Korean](translations/mmr_KR.md), [简体中文](translations/mmr_ZH-CN.md).* ## Structure @@ -145,7 +145,7 @@ Height 2 6 13 / / \ 1 2 9 12 17 - \ / / \ / + \ / / \ / 0 1 7 10 11 15 18 ``` diff --git a/doc/p2p/p2p_protocol.md b/doc/p2p/p2p_protocol.md new file mode 100644 index 0000000000..a20c16682e --- /dev/null +++ b/doc/p2p/p2p_protocol.md @@ -0,0 +1,277 @@ +# P2P Protocol + +## P2P Messages + +#### WARNING: This document is still in progress and has not yet been reviewed by any of the core Grin developers. + +* All fields are serialized in Big-Endian byte order unless otherwise specified. +* Variable-length strings (VAR_STR) are encoded in UTF8, and are preceded with a uint64 indicating their lengths. + +### Message Types + +There are currently 19 different types of P2P Messages: + +| Id | Message Type | Description | +|----|------------------|------------------------------------------------------------------------------------------------------------------------------------------| +| 0 | Error | Sent when an issue is found during communication with a peer. Usually followed by closing the connection. | +| 1 | Hand | First part of a handshake, sender advertises its version and characteristics. | +| 2 | Shake | Second part of a handshake, receiver of the first part replies with its own version and characteristics. | +| 3 | Ping | Sent to confirm that the connection is still valid, and used to advertise the node's total_difficulty to confirm whether sync is needed. | +| 4 | Pong | The response to a ping message. | +| 5 | GetPeerAddrs | Used to request addresses of new peers to connect to. | +| 6 | PeerAddrs | Peer addresses sent in response to a GetPeerAddrs message. | +| 7 | GetHeaders | Used to request block headers from a peer. | +| 8 | Header | A single block header received from a peer. | +| 9 | Headers | Multiple block headers received from a peer in response to a GetHeaders message. | +| 10 | GetBlock | Used to request a block from a peer. | +| 11 | Block | A single block received from a peer. | +| 12 | GetCompactBlock | Used to request a compact block from a peer. | +| 13 | CompactBlock | A single compact block received from a peer. | +| 14 | StemTransaction | A stem transaction received from a peer. | +| 15 | Transaction | A transaction received from a peer. | +| 16 | TxHashSetRequest | Used to request the transaction hashset from a peer. | +| 17 | TxHashSetArchive | The transaction hashset in response to the TxHashSetRequest message. | +| 18 | BanReason | Contains the reason your node was banned by a peer. | + +### Message structure + +All P2P messages follow a generic message structure as follows. + +| Size | Name | Data Type | Description/Comments | +|------|---------|-----------------|-----------------------------------------------------------------------------------| +| 2 | Magic | uint8[2] | Magic number used to identify Grin packets. Always hard-coded as {0x1E, 0xC5}. | +| 1 | Type | MessageTypeEnum | Identifier of the packet content. | +| 8 | Length | uint64 | The total length of the message. This will not include the header size (11 bytes).| +| ? | Payload | uint8[] | The actual data. | + +TODO: Provide example + +### Common structures + +##### SocketAddress + +| Size | Name | Data Type | Description/Comments | +|------|-----------------|--------------------|-------------------------------------------------------------| +| 1 | IPAddressFamily | uint8 | Identifies the IP address family. 0 = IPv4, 1 = IPv6. | +| 4/16 | IPAddress | uint8[4]/uint16[8] | The IP address. 4 octets for IPv4 or 8 hexadecets for IPv6. | +| 2 | Port | uint16 | The TCP/IP port number. | + +##### CapabilitiesMask + +| Value | Name | Description | +|-------|-------------------|----------------------------------------------------------------------------| +| 0x00 | Unknown | We don't know (yet) what the peer can do. | +| 0x01 | Full History | Full archival node, has the whole history without any pruning. | +| 0x02 | TxHashSet History | Can provide block headers and the TxHashSet for some recent-enough height. | +| 0x04 | Peer List | Can provide a list of healthy peers. | +| 0x06 | Fast Sync Node | Both "TxHashSet History" and "Peer List" | +| 0x07 | Full Node | "Full History", "TxHashSet History", and "Peer List" | + +##### TransactionBody + +| Size | Name | Data Type | Description/Comments | +|------|---------|------------|--------------------------------------------------------------------------| +| ? | Inputs | TxInput[] | List of inputs spent by the transaction. | +| ? | Outputs | TxOutput[] | List of outputs the transaction produces. | +| ? | Kernels | TxKernel[] | List of kernels that make up this transaction (usually a single kernel). | + +##### CompactBlockBody + +| Size | Name | Data Type | Description/Comments | +|------|-------------|------------|-----------------------------------------------------------------------------------------| +| ? | FullOutputs | TxOutput[] | List of full outputs - specifically the coinbase output(s). | +| ? | FullKernels | TxKernel[] | List of full kernels - specifically the coinbase kernel(s). | +| ? | KernelIds | ShortId[] | List of transaction kernels, excluding those in the full list. Each ShortId is 6 bytes. | + +##### TxInput + +##### TxOutput + +##### TxKernel + +##### ProofOfWork + +| Size | Name | Data Type | Description/Comments | +|------|-------------------|------------|-----------------------------------------------------------------| +| 8 | TotalDifficulty | uint64 | Total accumulated difficulty since genesis block. | +| 4 | ScalingDifficulty | uint32 | Difficulty scaling factor between the different proofs of work. | +| 8 | Nonce | uint64 | Nonce increment used to mine the block. | +| 1 | EdgeBits | uint8 | Power of 2 used for the size of the cuckoo graph. | +| 336 | ProofNonces | uint64[42] | The cuckoo proof nonces. | + +### Messages + +##### Error + +| Size | Name | Data Type | Description/Comments | +|------|---------|-----------|----------------------------------------------| +| 4 | Code | uint32 | Error Code. TODO: Determine possible values. | +| ? | Message | VAR_STR | Slightly more user-friendly message | + +##### Hand + +| Size | Name | Data Type | Description/Comments | +|------|-----------------|------------------|--------------------------------------------------------------------------------------------| +| 4 | Version | uint32 | Protocol version of the sender. | +| 1 | Capabilities | CapabilitiesMask | Bitmask representing the capabilities of the sender. | +| 8 | Nonce | uint64 | Randomly generated for each handshake to help detect connections to yourself. | +| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. | +| 7/19 | SenderAddress | SocketAddress | Network address of the sender. 7 bytes for IPv4 or 19 bytes for IPv6. | +| 7/19 | ReceiverAddress | SocketAddress | Network address of the receiver. 7 bytes for IPv4 or 19 bytes for IPv6. | +| ? | UserAgent | VAR_STR | Name and version of the software. Example: "MW/Grin 0.1.2" | +| 32 | Hash | uint8[32] | Genesis block of the current chain. Testnet1/2/3 and mainnet all have a different genesis. | + +##### Shake + +| Size | Name | Data Type | Description/Comments | +|------|-----------------|------------------|--------------------------------------------------------------------------------------------| +| 4 | Version | uint32 | Protocol version of the sender. | +| 1 | Capabilities | CapabilitiesMask | Bitmask representing the capabilities of the sender. | +| 8 | Nonce | uint64 | Randomly generated for each handshake to help detect connections to yourself. | +| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. | +| ? | UserAgent | VAR_STR | Name and version of the software. Example: "MW/Grin 0.1.2" | +| 32 | Hash | uint8[32] | Genesis block of the current chain. Testnet1/2/3 and mainnet all have a different genesis. | + +##### Ping + +| Size | Name | Data Type | Description/Comments | +|------|-----------------|-----------|-----------------------------------------------------------------------------------------------------| +| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. | +| 8 | Height | uint64 | Total block height accumulated by the sender. See: https://github.com/mimblewimble/grin/issues/1779 | + +##### Pong + +| Size | Name | Data Type | Description/Comments | +|------|-----------------|-----------|-----------------------------------------------------------------------------------------------------| +| 8 | TotalDifficulty | uint64 | Total difficulty accumulated by the sender. Used to check whether sync may be needed. | +| 8 | Height | uint64 | Total block height accumulated by the sender. See: https://github.com/mimblewimble/grin/issues/1779 | + +##### GetPeerAddrs + +| Size | Name | Data Type | Description/Comments | +|------|--------------|------------------|----------------------------------------| +| 1 | Capabilities | CapabilitiesMask | The capabilities the peer should have. | + +##### PeerAddrs + +| Size | Name | Data Type | Description/Comments | +|------|-------|-----------------|---------------------------------------------------------------------------| +| 4 | Size | uint32_t | The number of peer addresses received. | +| ? | Peers | SocketAddress[] | Peer addresses that match the criteria from the GetPeerAddresses request. | + +##### GetHeaders + +| Size | Name | Data Type | Description/Comments | +|------|--------|-----------|------------------------------------------------------------------| +| 1 | Size | uint8_t | The number of headers being requested. | +| ? | Hashes | Hash[] | The 32-byte Blake2b hashes of the block headers being requested. | + +##### Header + +| Size | Name | Data Type | Description/Comments | +|------|-------------------|----------------|--------------------------------------------------------------------------------| +| 2 | Version | uint16 | The version of the block. | +| 8 | Height | uint64 | Height of this block since the genesis block (height 0). | +| 8 | Timestamp | int64 | Timestamp at which the block was built. | +| 32 | Previous | Hash | Blake2b hash of the block previous to this in the chain. | +| 32 | PreviousRoot | Hash | Merklish root of all the commitments in the previous block's TxHashSet. | +| 32 | OutputRoot | Hash | Merklish root of all the commitments in the TxHashSet. | +| 32 | RangeProofRoot | Hash | Merklish root of all range proofs in the TxHashSet. | +| 32 | KernelRoot | Hash | Merklish root of all transaction kernels in the TxHashSet. | +| 32 | TotalKernelOffset | BlindingFactor | Total accumulated sum of kernel offsets since genesis block. | +| 8 | OutputMMRSize | uint64 | Total size of the output Merkle Mountain Range(MMR) after applying this block. | +| 8 | KernelMMRSize | uint64 | Total size of the kernel MMR after applying this block. | +| 178 | ProofOfWork | ProofOfWork | Proof of work and related. | + +##### Headers + +| Size | Name | Data Type | Description/Comments | +|------|---------|---------------|--------------------------------------------------------------------------| +| 2 | Size | uint16_t | The number of headers received. | +| ? | Headers | BlockHeader[] | The headers matching the hashes provided in the GetBlockHeaders request. | + +##### GetBlock + +| Size | Name | Data Type | Description/Comments | +|------|-----------|-----------|------------------------------------------------| +| 32 | BlockHash | Hash | The Blake2b hash of the block being requested. | + +##### Block + +| Size | Name | Data Type | Description/Comments | +|------|--------|-----------------|----------------------------------------------------------------------| +| 405 | Header | BlockHeader | The block header. | +| ? | Body | TransactionBody | The block transaction containing the inputs, outputs, and kernel(s). | + +##### GetCompactBlock + +| Size | Name | Data Type | Description/Comments | +|------|-----------|-----------|--------------------------------------------------------| +| 32 | BlockHash | Hash | The Blake2b hash of the compact block being requested. | + +##### CompactBlock + +| Size | Name | Data Type | Description/Comments | +|------|--------|------------------|----------------------------------------------------------------------| +| 405 | Header | BlockHeader | The header with metadata and commitments to the rest of the data. | +| 8 | Nonce | uint64 | Nonce for connection specific short_ids. | +| ? | Body | CompactBlockBody | Container for out_full, kern_full and kern_ids in the compact block. | + +##### StemTransaction + +| Size | Name | Data Type | Description/Comments | +|------|--------|-----------------|---------------------------------------------------------------------| +| 32 | Offset | BlindingFactor | The kernel "offset" k2. | +| ? | Body | TransactionBody | The transaction body containing the inputs, outputs, and kernel(s). | + +##### Transaction + +| Size | Name | Data Type | Description/Comments | +|------|--------|-----------------|---------------------------------------------------------------------| +| 32 | Offset | BlindingFactor | The kernel "offset" k2. | +| ? | Body | TransactionBody | The transaction body containing the inputs, outputs, and kernel(s). | + +##### TxHashSetRequest + +| Size | Name | Data Type | Description/Comments | +|------|-----------|-----------|-----------------------------------------------------------------------| +| 32 | BlockHash | Hash | Blake2b hash of the block for which the TxHashSet should be provided. | +| 8 | Height | uint64 | Height of the corresponding block. | + +##### TxHashSetArchive + +The response to a TxHashSetRequest. Includes a zip stream of the archive after the message body. + +| Size | Name | Data Type | Description/Comments | +|------|-----------|-----------|-----------------------------------------------------------------| +| 32 | BlockHash | Hash | Blake2b hash of the block for which the txhashset are provided. | +| 8 | Height | uint64 | Height of the corresponding block. | +| 8 | Bytes | uint64 | Size in bytes of the archive. | + + +##### BanReason + +| Size | Name | Data Type | Description/Comments | +|------|-----------|------------------|-------------------------| +| 4 | BanReason | ReasonForBanEnum | The reason for the ban. | + + +## Protocol Versions and Capabilities + +### Capabilities + +Any feature that users will have the ability to disable should be implemented as a new capability (See CapabilitiesMask above). This includes things like archive mode/full history. + +### Protocol Version + +Any change to the p2p protocol that is not toggled by the addition of a new capability should result in an increase in protocol version (See Hand & Shake messages above). This includes any addition or removal of a field or entire message, or any backward-incompatible behavior change to an existing field or message. When interacting with peers on an older protocol version, backward compatibility must be maintained, so the newer node should follow the rules of the older protocol version. + +##### Phasing out old peers + +To reduce the long-term complexity of the code, we can periodically bump the "major" protocol version. Although the protocol version is just a uint32, we can consider every increase by 1000 a new "major" protocol version. We can then gracefully phase out stubborn peers that refuse to upgrade by only supporting 1 major protocol version in the past. Here's what this would look like in practice: + +* Peers with a protocol version in the range [0-999] should be able to interact with any peer in the range [0-1999]. +* Peers with a protocol version in the range [1000-1999] should be able to interact with any peer in the range [0-2999]. +* Peers with a protocol version in the range [2000-2999] should be able to interact with any peer in the range [1000-3999]. + +Determining when to increase the "major" version is left up to the discretion of the developers. Care must be taken to ensure we are not increasing too quickly however, as any major bump could result in the inability to connect to certain older peers. diff --git a/doc/pruning.md b/doc/pruning.md index 9f1319684e..48daaca466 100644 --- a/doc/pruning.md +++ b/doc/pruning.md @@ -1,6 +1,6 @@ # Pruning Blockchain Data -*Read this in other languages: [Korean](pruning_KR.md), [简体中文](pruning_ZH-CN.md).* +*Read this in other languages: [Korean](translations/pruning_KR.md), [简体中文](translations/pruning_ZH-CN.md).* One of the principal attractions of Mimblewimble is its theoretical space efficiency. Indeed, a trusted or pre-validated full blockchain state only diff --git a/doc/state.md b/doc/state.md index 9ccabfc273..f56a650c66 100644 --- a/doc/state.md +++ b/doc/state.md @@ -1,6 +1,6 @@ # State and Storage -*Read this in other languages: [Korean](state_KR.md), [日本語](state_JP.md), [简体中文](state_ZH-CN.md).* +*Read this in other languages: [Korean](translations/state_KR.md), [日本語](translations/state_JP.md), [简体中文](translations/state_ZH-CN.md).* ## The Grin State diff --git a/doc/stratum.md b/doc/stratum.md index 7f09323615..6e3d28fe16 100644 --- a/doc/stratum.md +++ b/doc/stratum.md @@ -1,6 +1,6 @@ # Grin Stratum RPC Protocol -*Read this in other languages: [Korean](stratum_KR.md), [简体中文](stratum_ZH-CN.md).* +*Read this in other languages: [Korean](translations/stratum_KR.md), [简体中文](translations/stratum_ZH-CN.md).* This document describes the current Stratum RPC protocol implemented in Grin. @@ -33,11 +33,11 @@ At any point, if miner the tries to do one of the following request (except logi Example: ```JSON -{ +{ "id":"10", "jsonrpc":"2.0", "method":"getjobtemplate", - "error":{ + "error":{ "code":-32500, "message":"login first" } @@ -56,11 +56,11 @@ if the request is not one of the following, the stratum server will give this er Example: ```JSON -{ +{ "id":"10", "jsonrpc":"2.0", "method":"getgrins", - "error":{ + "error":{ "code":-32601, "message":"Method not found" } @@ -84,7 +84,7 @@ Miner can request a job with this message. Example: ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"getjobtemplate", @@ -101,11 +101,11 @@ The response can be of two types: Example: ``` JSON -{ +{ "id":"0", "jsonrpc":"2.0", "method":"getjobtemplate", - "result":{ + "result":{ "difficulty":1, "height":13726, "job_id":4, @@ -128,11 +128,11 @@ If the node is syncing, it will send the following message: Example: ```JSON -{ +{ "id":"10", "jsonrpc":"2.0", "method":"getjobtemplate", - "error":{ + "error":{ "code":-32000, "message":"Node is syncing - Please wait" } @@ -157,11 +157,11 @@ The miner SHOULD interrupt current job if job_id = 0, and SHOULD replace the cur Example: ``` JSON -{ +{ "id":"Stratum", "jsonrpc":"2.0", "method":"job", - "params":{ + "params":{ "difficulty":1, "height":16375, "job_id":5, @@ -190,7 +190,7 @@ A message initiated by the miner in order to keep the connection alive. Example: ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"keepalive", @@ -211,7 +211,7 @@ Example: Example: ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"keepalive", @@ -240,11 +240,11 @@ Example: ``` JSON -{ +{ "id":"0", "jsonrpc":"2.0", "method":"login", - "params":{ + "params":{ "login":"login", "pass":"password", "agent":"grin-miner" @@ -269,7 +269,7 @@ The response can be of two types: Example: ``` JSON -{ +{ "id":"1", "jsonrpc":"2.0", "method":"login", @@ -299,7 +299,7 @@ This message allows a miner to get the status of its current worker and the netw Example: ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"status", @@ -322,11 +322,11 @@ The response is the following: Example: ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"status", - "result":{ + "result":{ "id":"5", "height":13726, "difficulty":1, @@ -366,7 +366,7 @@ Example: "height":16419, "job_id":0, "nonce":8895699060858340771, - "pow":[ + "pow":[ 4210040,10141596,13269632,24291934,28079062,84254573,84493890,100560174,100657333,120128285,130518226,140371663,142109188,159800646,163323737,171019100,176840047,191220010,192245584,198941444,209276164,216952635,217795152,225662613,230166736,231315079,248639876,263910393,293995691,298361937,326412694,330363619,414572127,424798984,426489226,466671748,466924466,490048497,495035248,496623057,502828197, 532838434 ] } @@ -392,7 +392,7 @@ The share is accepted by the Stratum but is not a valid cuck(at)oo solution at t Example: ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"submit", @@ -416,7 +416,7 @@ The share is accepted by the Stratum and is a valid cuck(at)oo solution at the n Example: ``` JSON -{ +{ "id":"6", "jsonrpc":"2.0", "method":"submit", @@ -443,11 +443,11 @@ The share is a valid solution to a previous job not the current one. Example: ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"submit", - "error":{ + "error":{ "code":-32503, "message":"Solution submitted too late" } @@ -472,11 +472,11 @@ The submitted solution cannot be validated. Example: ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"submit", - "error":{ + "error":{ "code":-32502, "message":"Failed to validate solution" } @@ -497,11 +497,11 @@ The submitted solution is of too low difficulty. Example: ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"submit", - "error":{ + "error":{ "code":-32501, "message":"Share rejected due to low difficulty" } diff --git a/doc/switch_commitment.md b/doc/switch_commitment.md index d43b846f68..22f472c163 100644 --- a/doc/switch_commitment.md +++ b/doc/switch_commitment.md @@ -1,6 +1,6 @@ # Introduction to Switch Commitments -*Read this in other languages: [简体中文](switch_commitment_ZH-CN.md).* +*Read this in other languages: [简体中文](translations/switch_commitment_ZH-CN.md).* ## General introduction @@ -51,7 +51,7 @@ get a single box as result (which still is locked), and if you open this single from _box1_ and _box2_. While this "box" metaphor no longer seems to be reasonable in the real-world this -is perfectly possible using the properties of operations on elliptic curves. +is perfectly possible using the properties of operations on elliptic curves. Look into [Introduction to Mimblewimble](intro.md) for further details on Pedersen Commitments and how they are used in Grin. @@ -184,7 +184,7 @@ security of the new commitment scheme. Also, this has to happen **before** the s actually broken in the wild, otherwise the existing UTXOs no longer can be assumed to contain correct values. -In this situation [_Switch Commitments_](https://eprint.iacr.org/2017/237.pdf) offer a neat +In this situation [_Switch Commitments_](https://eprint.iacr.org/2017/237.pdf) offer a neat solution. These type of commitments allow changing the properties of the commitments just by changing the revealing / validating procedure without changing the way commitments are created. (You "_switch_" to a new validation scheme which is backwards @@ -268,20 +268,20 @@ important safety measure: Pedersen Commitments are already _perfectly hiding_ so whatever happens, privacy will never be at risk without requiring any action from users. But in case of a disaster if the -bindingness of the commitment scheme gets broken, then switch commitments can be enabled +bindingness of the commitment scheme gets broken, then switch commitments can be enabled (via a soft fork) requiring that all new transactions prove that their commitment is not -breaking the bindingness by validating the full ElGamal commitment. +breaking the bindingness by validating the full ElGamal commitment. But in this case users would still have a choice: - they can decide to continue to create new transactions, even if this might compromise - their privacy (only on their **last** UTXOs) as the ElGamal commitment scheme is + their privacy (only on their **last** UTXOs) as the ElGamal commitment scheme is only computationally hiding, but at least they would still have access to their coins - or users can decide to just leave the money alone, walk away and make no more transactions (but preserve their privacy, as their old transactions only validated the Pedersen commitment which is perfectly hiding) - + There are many cases where a privacy leak is much more dangerous to one's life than some cryptocurrency might be worth. But this is a decision that should be left up to diff --git a/doc/table_of_contents.md b/doc/table_of_contents.md index 650fcba3bc..3bc56cf803 100644 --- a/doc/table_of_contents.md +++ b/doc/table_of_contents.md @@ -1,6 +1,6 @@ # Documentation structure -*Read this in other languages: [Korean](table_of_contents_KR.md), [简体中文](table_of_contents_ZH-CN.md).* +*Read this in other languages: [Korean](translations/table_of_contents_KR.md), [简体中文](translations/table_of_contents_ZH-CN.md).* ## Explaining grin diff --git a/doc/build_ES.md b/doc/translations/build_ES.md similarity index 97% rename from doc/build_ES.md rename to doc/translations/build_ES.md index ca6d6ff9fa..61fbdf4e36 100644 --- a/doc/build_ES.md +++ b/doc/translations/build_ES.md @@ -1,6 +1,6 @@ # Grin - Compilación, configuración y ejecución -*Lea esto en otros idiomas: [English](build.md), [日本語](build_JP.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).* +*Lea esto en otros idiomas: [English](../build.md), [日本語](build_JP.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).* ## Plataformas soportadas diff --git a/doc/build_JP.md b/doc/translations/build_JP.md similarity index 97% rename from doc/build_JP.md rename to doc/translations/build_JP.md index 12006cb5dd..c6ffa335a5 100644 --- a/doc/build_JP.md +++ b/doc/translations/build_JP.md @@ -1,6 +1,6 @@ # grin - ビルド、設定、動作確認 -*この文章を他の言語で読む: [English](build.md), [Español](build_ES.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).* +*この文章を他の言語で読む: [English](../build.md), [Español](build_ES.md), [Korean](build_KR.md), [简体中文](build_ZH-CN.md).* ## 動作環境 diff --git a/doc/build_KR.md b/doc/translations/build_KR.md similarity index 98% rename from doc/build_KR.md rename to doc/translations/build_KR.md index 0f84d76c41..0658030382 100644 --- a/doc/build_KR.md +++ b/doc/translations/build_KR.md @@ -1,6 +1,6 @@ # Grin - Build, Configuration, and Running -*다른 언어로 되어있는 문서를 읽으려면: [English](build.md), [Español](build_ES.md), [日本語](build_JP.md), [简体中文](build_ZH-CN.md).* +*다른 언어로 되어있는 문서를 읽으려면: [English](../build.md), [Español](build_ES.md), [日本語](build_JP.md), [简体中文](build_ZH-CN.md).* ## 지원하는 플랫폼들에 대해서 diff --git a/doc/build_ZH-CN.md b/doc/translations/build_ZH-CN.md similarity index 97% rename from doc/build_ZH-CN.md rename to doc/translations/build_ZH-CN.md index 965c9508c7..d24444b93b 100644 --- a/doc/build_ZH-CN.md +++ b/doc/translations/build_ZH-CN.md @@ -1,6 +1,6 @@ # Grin - 构建，配置和运行 -*阅读其它语言版本: [English](build.md), [Español](build_ES.md), [日本語](build_JP.md), [Korean](build_KR.md).* +*阅读其它语言版本: [English](../build.md), [Español](build_ES.md), [日本語](build_JP.md), [Korean](build_KR.md).* ## 支持的平台 diff --git a/doc/code_structure_ZH-CN.md b/doc/translations/code_structure_ZH-CN.md similarity index 98% rename from doc/code_structure_ZH-CN.md rename to doc/translations/code_structure_ZH-CN.md index bb1ad4a94f..11bddabbdc 100644 --- a/doc/code_structure_ZH-CN.md +++ b/doc/translations/code_structure_ZH-CN.md @@ -1,6 +1,6 @@ # Grin 代码结构 -*阅读其它语言版本: [English](code_structure.md).* +*阅读其它语言版本: [English](../code_structure.md).* Grin 使用 [Rust]（https://www.rust-lang.org/）编写，这是一个内存安全的编译语言。诸如 Cuckoo 挖掘算法之类的性能关键部分都是作为插件构建的，因此可以轻松地在各种硬件的算法实现之间进行交换。Grin 带有 CPU 和实验性 GPU 支持。 diff --git a/doc/coinbase_maturity_KR.md b/doc/translations/coinbase_maturity_KR.md similarity index 100% rename from doc/coinbase_maturity_KR.md rename to doc/translations/coinbase_maturity_KR.md diff --git a/doc/coinbase_maturity_ZH-CN.md b/doc/translations/coinbase_maturity_ZH-CN.md similarity index 97% rename from doc/coinbase_maturity_ZH-CN.md rename to doc/translations/coinbase_maturity_ZH-CN.md index eaef3b4836..ecef4f6bae 100644 --- a/doc/coinbase_maturity_ZH-CN.md +++ b/doc/translations/coinbase_maturity_ZH-CN.md @@ -1,6 +1,6 @@ # Coinbase 期限规则（亦即"输出锁定高度"） -*阅读其它语言版本: [English](coinbase_maturity.md), [Korean](coinbase_maturity_KR.md).* +*阅读其它语言版本: [English](../coinbase_maturity.md), [Korean](coinbase_maturity_KR.md).* coinbase 输出（区块奖励和手续费）为“锁定”，需要有 1440 个确认（也就是经过约 24 小时在链上加上区块）才能到期花费。这是为了防止之后如果出现链上回滚的情况下，降低撤销之后交易的风险。 @@ -126,4 +126,4 @@ Grin 不允许在输出组中重复的秘诺同时存在。但输出组特指特 * 原始区块的区块哈希 * [待确定 - 根据默克尔证明维护索引？] -通过秘诺和特征确定正确的输出目前是否未花费。通过区块和输出特征确定锁定高度（如有）。 \ No newline at end of file +通过秘诺和特征确定正确的输出目前是否未花费。通过区块和输出特征确定锁定高度（如有）。 diff --git a/doc/contract_ideas_ZH-CN.md b/doc/translations/contract_ideas_ZH-CN.md similarity index 100% rename from doc/contract_ideas_ZH-CN.md rename to doc/translations/contract_ideas_ZH-CN.md diff --git a/doc/contracts_ZH-CN.md b/doc/translations/contracts_ZH-CN.md similarity index 100% rename from doc/contracts_ZH-CN.md rename to doc/translations/contracts_ZH-CN.md diff --git a/doc/fast-sync_ES.md b/doc/translations/fast-sync_ES.md similarity index 67% rename from doc/fast-sync_ES.md rename to doc/translations/fast-sync_ES.md index 7af35ce962..502a4b961c 100644 --- a/doc/fast-sync_ES.md +++ b/doc/translations/fast-sync_ES.md @@ -1,19 +1,19 @@ # Sincronización rápida -*Lea esto en otros idiomas: [English](fast-sync.md), [简体中文](fast-sync_ZH-CN.md), [Korean](fast-sync_KR.md).* +*Lea esto en otros idiomas: [English](../fast-sync.md), [简体中文](fast-sync_ZH-CN.md), [Korean](fast-sync_KR.md).* -En Grin, llamamos "sync" al proceso de sincronizar un nuevo nodo o un nodo que no ha estado al día con la cadena durante un -tiempo, y llevarlo hasta el último bloque conocido. La Descarga Inicial de Bloques (o IBD) es usada a menudo por otras cadenas +En Grin, llamamos "sync" al proceso de sincronizar un nuevo nodo o un nodo que no ha estado al día con la cadena durante un +tiempo, y llevarlo hasta el último bloque conocido. La Descarga Inicial de Bloques (o IBD) es usada a menudo por otras cadenas de bloques, pero esto es problemático para Grin ya que típicamente no descarga bloques completos.. En resumen, una sincronización rápida en Grin hace lo siguiente: -1. Descargar todas las cabeceras de los bloques, por trozos, en la cadena más utilizada, +1. Descargar todas las cabeceras de los bloques, por trozos, en la cadena más utilizada, tal y como lo anuncian otros nodos. -1. Encuentre una cabecera suficientemente alejada del encabezado de la cadena. Esto se denomina horizonte de nodo, ya que es lo - más lejos que un nodo puede reorganizar su cadena en una nueva bifurcación en caso de que ocurriera sin activar otra nueva +1. Encuentre una cabecera suficientemente alejada del encabezado de la cadena. Esto se denomina horizonte de nodo, ya que es lo + más lejos que un nodo puede reorganizar su cadena en una nueva bifurcación en caso de que ocurriera sin activar otra nueva sincronización completa. -1. Descargue el estado completo tal y como estaba en el horizonte, incluyendo los datos de salida no utilizados, los datos de +1. Descargue el estado completo tal y como estaba en el horizonte, incluyendo los datos de salida no utilizados, los datos de pruebas de rango y del núcleo, así como todos los MMR correspondientes. Este es sólo un gran archivo zip. 1. Validar el estado total. 1. Descarga bloques completos desde el horizonte para llegar a la cabeza de la cadena. diff --git a/doc/fast-sync_KR.md b/doc/translations/fast-sync_KR.md similarity index 95% rename from doc/fast-sync_KR.md rename to doc/translations/fast-sync_KR.md index edb716466e..d2a3acf742 100644 --- a/doc/fast-sync_KR.md +++ b/doc/translations/fast-sync_KR.md @@ -1,6 +1,6 @@ # 빠른 동기화 -*다른 언어로 되어있는 문서를 읽으려면: [English](fast-sync.md), [Español](fast-sync_ES.md), [简体中文](fast-sync_ZH-CN.md).* +*다른 언어로 되어있는 문서를 읽으려면: [English](../fast-sync.md), [Español](fast-sync_ES.md), [简体中文](fast-sync_ZH-CN.md).* Grin에서는 새로 네트워크에 참여하는 노드나 얼마 동안 체인을 따라 잡지 않은 노드(의 상태)를 알려진 최신 블록으로( 원문에서는 most-worked block 이라고 표현- 역자 주 ) 가져 오는 프로세스를 "동기화"라고 부릅니다. Initial Block Download (또는 IBD)는 다른 블록 체인에서 자주 사용되지만 빠른 동기화를 사용하는 Grin에서는 일반적으로 전체 블록을 다운로드하지 않으므로 문제가 됩니다. diff --git a/doc/fast-sync_ZH-CN.md b/doc/translations/fast-sync_ZH-CN.md similarity index 90% rename from doc/fast-sync_ZH-CN.md rename to doc/translations/fast-sync_ZH-CN.md index ba2272fba8..8ba592af01 100644 --- a/doc/fast-sync_ZH-CN.md +++ b/doc/translations/fast-sync_ZH-CN.md @@ -1,6 +1,6 @@ # 快速同步 -*阅读其它语言版本: [English](fast-sync.md), [Español](fast-sync_ES.md), [Korean](fast-sync_KR.md).* +*阅读其它语言版本: [English](../fast-sync.md), [Español](fast-sync_ES.md), [Korean](fast-sync_KR.md).* 在 Grin 中，我们把同步一个新节点或一段时间未跟上链的节点，并将其升级到最新的已知工作量最大的块的过程称为“同步”（"sync"）。 初始块下载（或 IBD）通常在其他区块链中被采用，但这对 Grin 来说这是有问题的，因为它通常不会下载完整的块。 diff --git a/doc/grin4bitcoiners_KR.md b/doc/translations/grin4bitcoiners_KR.md similarity index 100% rename from doc/grin4bitcoiners_KR.md rename to doc/translations/grin4bitcoiners_KR.md diff --git a/doc/grin4bitcoiners_ZH-CN.md b/doc/translations/grin4bitcoiners_ZH-CN.md similarity index 97% rename from doc/grin4bitcoiners_ZH-CN.md rename to doc/translations/grin4bitcoiners_ZH-CN.md index 42d1b6030e..6dcde20b24 100644 --- a/doc/grin4bitcoiners_ZH-CN.md +++ b/doc/translations/grin4bitcoiners_ZH-CN.md @@ -1,7 +1,7 @@ # Grin/Mimblewimble 致比特币持有者 -* 阅读其他语言版本：[Korean](grin4bitcoiners_KR.md)、 [English](grin4bitcoiners.md) +*阅读其他语言版本： [English](../grin4bitcoiners.md), [Korean](grin4bitcoiners_KR.md).* ## 隐私和可互换性 diff --git a/doc/intro_DE.md b/doc/translations/intro_DE.md similarity index 97% rename from doc/intro_DE.md rename to doc/translations/intro_DE.md index 56b6f627fd..60e7c89859 100644 --- a/doc/intro_DE.md +++ b/doc/translations/intro_DE.md @@ -1,6 +1,6 @@ # Einführung in Mimblewimble und Grin -*In anderen Sprachen lesen: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md)* +*In anderen Sprachen lesen: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md)* Mimblewimble ist ein Blockchain-Format und Protokoll, welches auf starke kryptographische Primitiven setzt und dadurch äußerst gute Skalierbarkeit, Privatsphäre und Fungibilität bietet. Es befasst sich mit Lücken, die in fast allen gegenwärtigen Blockchainimplementierungen existieren. @@ -18,13 +18,13 @@ Das Hauptziel und die Charakteristika des Grin-Projekts sind wie folgt: Dieses Dokument richtet sich an Leser, die ein gutes Verständnis von Blockchain und grundlegender Kryptografie haben. Vor diesem Hintergrund sind wir bestrebt, den technischen Aufbau von Mimblewimble, sowie dessen Einsatz in Grin zu erklären. Wir hoffen, dass dieses Dokument für die meisten technikbegeisterten Leser verständlich ist. Unser Ziel ist es, dich für Grin zu begeistern und dein Interesse zu wecken, dich in jeder möglichen Weise einzubringen. -Um dieses Ziel zu erreichen, führen wir die für ein gutes Verständnis von Grin als Mimblewimble-Umsetzung nötigen Hauptkonzepte ein. Wir beginnen mit einer kurzen Erläutering einiger relevanter Eigenschaften der Elliptischen-Kurven-Kryptografie (ECC), um die Grundlagen für Grin zu legen und anschließend die Kernelemente von Transaktionen und Blocks im Mimblewimble-Blockchain zu beschreiben. +Um dieses Ziel zu erreichen, führen wir die für ein gutes Verständnis von Grin als Mimblewimble-Umsetzung nötigen Hauptkonzepte ein. Wir beginnen mit einer kurzen Erläutering einiger relevanter Eigenschaften der Elliptischen-Kurven-Kryptografie (ECC), um die Grundlagen für Grin zu legen und anschließend die Kernelemente von Transaktionen und Blocks im Mimblewimble-Blockchain zu beschreiben. ### Tiny Bits of Elliptic Curves Wir beginnen mit einer kurzen Einführung in Elliptische-Kurven-Kryptografie, wobei wir nur die Eigenschaften betrachten, die für das Verständnis von Mimblewimbles Funktionsweise nötig sind, ohne die Feinheiten von ECC eingehend zu vertiefen. Für Leser, die tiefer in diese Vorraussetzungen einzutauchen wünschen, gibt es weitere Möglichkeiten [mehr zu lernen](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). -Eine elliptische Kurve zum Zwecke der Kryptografie ist ein großes Set an Punkten, die wir _C_ nennen. Diese Punkte können von Integern (auch Skalare genannt) addiert, substrahiert, oder multipliziert werden. Mit einem Integer _k_ und mittels einer Operation der skalaren Multiplikation können wir `k*H` errechnen, was auch einen Punkt auf der Kurve _C_ darstellt. Mit einem weiteren Integer _j_ können wir ferner `(k+j)*H` errechnen, was `k*H + j*H` gleicht. Diese Addition- und Skalarmultiplikationsoperationen auf einer elliptischen Kurve behalten die kommutativen und assoziativen Eigenschaften der Addition und Multiplikation bei: +Eine elliptische Kurve zum Zwecke der Kryptografie ist ein großes Set an Punkten, die wir _C_ nennen. Diese Punkte können von Integern (auch Skalare genannt) addiert, substrahiert, oder multipliziert werden. Mit einem Integer _k_ und mittels einer Operation der skalaren Multiplikation können wir `k*H` errechnen, was auch einen Punkt auf der Kurve _C_ darstellt. Mit einem weiteren Integer _j_ können wir ferner `(k+j)*H` errechnen, was `k*H + j*H` gleicht. Diese Addition- und Skalarmultiplikationsoperationen auf einer elliptischen Kurve behalten die kommutativen und assoziativen Eigenschaften der Addition und Multiplikation bei: (k+j)*H = k*H + j*H @@ -59,7 +59,7 @@ Ein Input- oder Outputwert in einer Transaktion kann sodann ausgedrückt werden Wobei: -* _r_ ein privater Schlüssel ist, der als Blinding Factor genutzt wird, _G_ eine elliptische Kurve, und deren Produkt `r*G` der öffentliche Schlüssel für _r_ auf _G_ ist. +* _r_ ein privater Schlüssel ist, der als Blinding Factor genutzt wird, _G_ eine elliptische Kurve, und deren Produkt `r*G` der öffentliche Schlüssel für _r_ auf _G_ ist. * _v_ der Wert eines Inputs oder Outputs und _H_ eine weitere elliptische Kurve ist. Weder _v_ noch _r_ können abgeleitet werden, was die grundlegenden Eigenschaften der Elliptischen-Kurven-Kryptografie wirksam zum Einsatz bringt. `r*G + v*H` wird als ein _Pedersen Commitment_ bezeichnet. @@ -73,7 +73,7 @@ Sodass vi1 + vi2 = vo3 -Durch die Erstellung eines privaten Schlüssels als Blinding Factor für jeden Inputwert und das Austauschen jedes Wertes mit den respektiven Pedersen Commitments der vorherigen Gleichung, erhalten wir: +Durch die Erstellung eines privaten Schlüssels als Blinding Factor für jeden Inputwert und das Austauschen jedes Wertes mit den respektiven Pedersen Commitments der vorherigen Gleichung, erhalten wir: (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) @@ -111,7 +111,7 @@ Um dies zu lösen, nutzt Carol einen privaten Schlüssel ihrer Wahl. Sie wählt Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H -Nun ergibt die Transaktion nicht länger Null und wir haben einen Wertüberschuss auf _G_ (85), was das Ergebnis der Summierung aller Blinding Factors ist. Weil aber `85*G` ein gültiger öffentlicher Schlüssel auf der elliptischen Kurve _C_, mit dem privaten Schlüssel 85, für jedes x und y, ist, gilt `x*G + y*H` nur dann als gültiger öffentlicher Schlüssel auf _G_, wenn `y = 0` ist. +Nun ergibt die Transaktion nicht länger Null und wir haben einen Wertüberschuss auf _G_ (85), was das Ergebnis der Summierung aller Blinding Factors ist. Weil aber `85*G` ein gültiger öffentlicher Schlüssel auf der elliptischen Kurve _C_, mit dem privaten Schlüssel 85, für jedes x und y, ist, gilt `x*G + y*H` nur dann als gültiger öffentlicher Schlüssel auf _G_, wenn `y = 0` ist. Daher muss das Protokoll lediglich verifizieren, dass (`Y - Xi`) ein gültiger öffentlicher Schlüssel auf _G_ ist, und dass die Transaktionspartner gemeinsam den privaten Schlüssel kennen (85 in unserer Transaktion mit Carol). Der einfachste Weg dies zu tun ist eine mit dem Wertüberschuss (85) erstellte Signature zu erfordern, die dann validiert, dass: @@ -139,7 +139,7 @@ Was auf die Blockchain gelangt ist sehr ähnlich wie zuvor. Die Signatur wird wi In allen obigen Berechnungen stützen wir uns darauf, dass die Transaktionswerte immer positiv sind. Die Einführung von negativen Beträgen wäre extrem problematisch, da in jeder Transaktion neue Gelder erstellt werden könnten. -Zum Beispiel könnten Transaktionen mit einem Input von 2 und Outputs von 5 und -3 erstellt werden, die trotzdem ausgeglichen sind, folgend der Definition in den vorherigen Abschnitten. Dies ist nicht einfach festzustellen, da sogar wenn _x_ Negativ ist, der korrespondierende Punkt `x.H` auf der Kurve so aussieht wie jeder andere. +Zum Beispiel könnten Transaktionen mit einem Input von 2 und Outputs von 5 und -3 erstellt werden, die trotzdem ausgeglichen sind, folgend der Definition in den vorherigen Abschnitten. Dies ist nicht einfach festzustellen, da sogar wenn _x_ Negativ ist, der korrespondierende Punkt `x.H` auf der Kurve so aussieht wie jeder andere. Um dieses Problem zu lösen, setzt Mimblewimble ein anderes kryptographisches Konzept (ebenso stammend von Confidential Transactions) namens Range Proofs ein. Wir werden Range Proofs nicht ausführlich behandeln, du solltest nur wissen, dass wir für jedes `r.G + v.H` einen Beweis erstellen können, der zeigt, dass _v_ größer als Null ist und nicht zu Overflow führt. @@ -149,7 +149,7 @@ Es ist auch wichtig anzumerken, dass um einen gültigen Range Proof der obigen B Eine Mimblewimble-Transaktion beinhaltet wie folgt: - * Eine Reihe von Inputs, die referenzieren, sowie eine Reihe an vorherigen Outputs ausgeben. + * Eine Reihe von Inputs, die referenzieren, sowie eine Reihe an vorherigen Outputs ausgeben. * Eine Reihe an neuen Outputs, die Folgendes umfassen: * einen Wert und ein Blinding Factor (welcher nur ein neuer privater Schlüssel ist) auf einer Kurve multipliziert und als `r.G + v.H` summiert. * Ein Range Proof der zeigt, dass v nicht negativ ist. @@ -213,7 +213,7 @@ Wir wissen auch, dass alles Übrige genutzt werden kann, um die andere gültige (in3) -> (out2), (kern2) -Um dies einzuschränken, beziehen wir einen _Kernel Offset_ in jedem Transaktionskernel mit ein. Dies ist ein Blinding Factor (privater Schlüssel) der zurück zum Kernel Excess hinzugefügt werden muss um zu verifizieren, dass die Summe der Commitments Null ergibt. +Um dies einzuschränken, beziehen wir einen _Kernel Offset_ in jedem Transaktionskernel mit ein. Dies ist ein Blinding Factor (privater Schlüssel) der zurück zum Kernel Excess hinzugefügt werden muss um zu verifizieren, dass die Summe der Commitments Null ergibt. sum(outputs) - sum(inputs) = kernel_excess + kernel_offset @@ -225,7 +225,7 @@ Wir "teilen" den Schlüssel `k` in `k1+k2` während des Aufbaus der Transaktion. #### Cut-through -Blocks erlauben es Minern multiple Transaktionen in einem einzelnen Set zusammenzustellen, welches der Chain hinzugefügt wird. In den folgenden Blockrepräsentationen, die 3 Transaktionen enthalten, zeigen wir nur Inputs und Outputs der Transaktionen. Inputs referenzieren die Outputs, die sie ausgeben. +Blocks erlauben es Minern multiple Transaktionen in einem einzelnen Set zusammenzustellen, welches der Chain hinzugefügt wird. In den folgenden Blockrepräsentationen, die 3 Transaktionen enthalten, zeigen wir nur Inputs und Outputs der Transaktionen. Inputs referenzieren die Outputs, die sie ausgeben. I1(x1) --- O1 |- O2 @@ -264,7 +264,7 @@ Sofern so strukturiert, bietet ein Mimblewimble-Block äußerst gute Garantie de * Intermediäre (cut-through) Transaktionen werden nur von ihren Transaktionskerneln repräsentiert. * Alle Outputs sehen gleich aus: nur sehr große Zahlen, die unmöglich voneinander differenzierbar sind. Um einige Outputs auszuschließen, müssten alle ausgeschlossen werden. -* Alle Transaktionsstrukturen wurden entfernt, was es unmöglich macht zu ermitteln, welches Output mit jedem Input verbunden wurde. +* Alle Transaktionsstrukturen wurden entfernt, was es unmöglich macht zu ermitteln, welches Output mit jedem Input verbunden wurde. Und doch validiert es alles noch immer! diff --git a/doc/intro_ES.md b/doc/translations/intro_ES.md similarity index 75% rename from doc/intro_ES.md rename to doc/translations/intro_ES.md index 4b6fef5fc5..70869b9119 100644 --- a/doc/intro_ES.md +++ b/doc/translations/intro_ES.md @@ -1,59 +1,59 @@ # Introducción a Mimblewimble y Grin -*Lea esto en otros idiomas: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* +*Lea esto en otros idiomas: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* -Mimblewimble es un formato y un protocolo de cadena de bloques que proporciona una escalabilidad, privacidad y funcionalidad -extremadamente buenas al basarse en fuertes algoritmos criptográficos. Aborda los vacíos existentes en casi todas las +Mimblewimble es un formato y un protocolo de cadena de bloques que proporciona una escalabilidad, privacidad y funcionalidad +extremadamente buenas al basarse en fuertes algoritmos criptográficos. Aborda los vacíos existentes en casi todas las implementaciones actuales de cadenas de bloques. -Grin es un proyecto de software de código abierto que implementa una cadena de bloques Mimblewimble y rellena los espacios +Grin es un proyecto de software de código abierto que implementa una cadena de bloques Mimblewimble y rellena los espacios necesarios para una implementación completa de la cadena de bloques y moneda criptográfica. El objetivo principal y las características del proyecto Grin son: -* Privacidad por defecto. Esto permite una funcionalidad completa sin excluir la posibilidad de revelar información de forma +* Privacidad por defecto. Esto permite una funcionalidad completa sin excluir la posibilidad de revelar información de forma selectiva cuando sea necesario. -* Se escala principalmente con el número de usuarios y mínimamente con el número de transacciones (`<100 bytes kernel`), lo +* Se escala principalmente con el número de usuarios y mínimamente con el número de transacciones (`<100 bytes kernel`), lo que resulta en un gran ahorro de espacio en comparación con otras cadenas de bloques. -* Criptografía robusta y probada. Mimblewimble sólo se basa en la criptografía de curvas elípticas que ha sido probada y +* Criptografía robusta y probada. Mimblewimble sólo se basa en la criptografía de curvas elípticas que ha sido probada y comprobada durante décadas. * Simplicidad de diseño que facilita la auditoría y el mantenimiento a lo largo del tiempo. -* Dirigido por la comunidad, utilizando un algoritmo de minería resistente a la ASICs (Cuckoo Cycle) que fomenta la +* Dirigido por la comunidad, utilizando un algoritmo de minería resistente a la ASICs (Cuckoo Cycle) que fomenta la descentralización de la minería. ## Tongue Tying para todos -Este documento está dirigido a lectores con un buen conocimiento de cadenas de bloques y de la criptografía básica. Con -esto en mente, tratamos de explicar el desarrollo técnico de Mimblewimble y cómo se aplica en Grin. Esperamos que este -documento sea comprensible para la mayoría de los lectores con visión técnica. Nuestro objetivo es animarles a interesarse en +Este documento está dirigido a lectores con un buen conocimiento de cadenas de bloques y de la criptografía básica. Con +esto en mente, tratamos de explicar el desarrollo técnico de Mimblewimble y cómo se aplica en Grin. Esperamos que este +documento sea comprensible para la mayoría de los lectores con visión técnica. Nuestro objetivo es animarles a interesarse en Grin y contribuir de cualquier manera posible. -Para lograr este objetivo, presentaremos los principales conceptos necesarios para una buena comprensión de Grin como -implementación de Mimblewimble. Comenzaremos con una breve descripción de algunas propiedades relevantes de la Criptografía -de Curva Elíptica (ECC) para sentar las bases sobre las que se basa Grin y luego describir todos los elementos clave de las +Para lograr este objetivo, presentaremos los principales conceptos necesarios para una buena comprensión de Grin como +implementación de Mimblewimble. Comenzaremos con una breve descripción de algunas propiedades relevantes de la Criptografía +de Curva Elíptica (ECC) para sentar las bases sobre las que se basa Grin y luego describir todos los elementos clave de las transacciones y bloques de una cadena de bloques Mimblewimble. ### Pequeños Bits de Curvas Elípticas -Comenzamos con una breve introducción a la Criptografía de Curva Elíptica, revisando sólo las propiedades necesarias para -entender cómo funciona MimblewimbleWimble y sin profundizar demasiado en las complejidades de ECC. Para los lectores que +Comenzamos con una breve introducción a la Criptografía de Curva Elíptica, revisando sólo las propiedades necesarias para +entender cómo funciona MimblewimbleWimble y sin profundizar demasiado en las complejidades de ECC. Para los lectores que deseen profundizar en estos supuestos, existen otras opciones para [aprender más](http://andrea.corbellini.name/2015/05/17/elliptic-curve-cryptography-a-gentle-introduction/). -Una curva elíptica con el objetivo de criptografía es simplemente un gran conjunto de puntos que llamaremos _C_. Estos puntos +Una curva elíptica con el objetivo de criptografía es simplemente un gran conjunto de puntos que llamaremos _C_. Estos puntos pueden sumarse, restarse o multiplicarse por números enteros (también llamados escalares). Dado un entero _k_ y -usando la operación de multiplicación escalar podemos calcular `k*H`, que es también un punto en la curva _C_. Dado otro -entero _j_ también podemos calcular `(k+j)*H`, que es igual a `k*H + j*H`. Las operaciones de suma y multiplicación escalar +usando la operación de multiplicación escalar podemos calcular `k*H`, que es también un punto en la curva _C_. Dado otro +entero _j_ también podemos calcular `(k+j)*H`, que es igual a `k*H + j*H`. Las operaciones de suma y multiplicación escalar en una curva elíptica mantienen las propiedades conmutativas y asociativas de suma y multiplicación: (k+j)*H = k*H + j*H -En ECC, si escogemos un número muy grande _k_ como clave privada, `k*H` se considera la clave pública correspondiente. -Incluso si uno conoce el valor de la clave pública `k*H`, deducir _k_ es casi imposible (o dicho de otra manera, mientras que +En ECC, si escogemos un número muy grande _k_ como clave privada, `k*H` se considera la clave pública correspondiente. +Incluso si uno conoce el valor de la clave pública `k*H`, deducir _k_ es casi imposible (o dicho de otra manera, mientras que la multiplicación es trivial, la "división" por puntos de curva es extremadamente difícil). -La fórmula anterior `(k+j)*H = k*H + j*H`, con _k_ y _j_ ambas claves privadas, demuestra que una clave pública obtenida de -la adición de dos claves privadas (`(k+j)*H`) es idéntica a la adición de las claves públicas para cada una de esas dos -claves privadas (`k*H + j*H`). En la cadena de bloques Bitcoin, las carteras jerárquicas deterministas se basan en gran +La fórmula anterior `(k+j)*H = k*H + j*H`, con _k_ y _j_ ambas claves privadas, demuestra que una clave pública obtenida de +la adición de dos claves privadas (`(k+j)*H`) es idéntica a la adición de las claves públicas para cada una de esas dos +claves privadas (`k*H + j*H`). En la cadena de bloques Bitcoin, las carteras jerárquicas deterministas se basan en gran medida en este principio. Mimblewimble y la implementación de Grin también lo hacen. ### Transacciones con Mimblewimble @@ -63,30 +63,30 @@ fuertes garantías de privacidad y confidencialidad. La validación de las transacciones de MimblewimbleWimble se basa en dos propiedades básicas: -* **Verificación de importes nulos.** La suma de las salidas menos las entradas siempre es igual a cero, lo que demuestra que +* **Verificación de importes nulos.** La suma de las salidas menos las entradas siempre es igual a cero, lo que demuestra que la transacción no creó nuevos fondos, _sin revelar los importes reales_. -* **Posesión de las claves privadas.** Como con la mayoría de las otras monedas criptográficas, la propiedad de los - resultados de las transacciones está garantizada por la posesión de claves privadas ECC. Sin embargo, la prueba de que una +* **Posesión de las claves privadas.** Como con la mayoría de las otras monedas criptográficas, la propiedad de los + resultados de las transacciones está garantizada por la posesión de claves privadas ECC. Sin embargo, la prueba de que una entidad es propietaria de esas claves privadas no se consigue firmando directamente la transacción. -Las siguientes secciones sobre el saldo, la propiedad, el intercambio y las verificaciones detallan cómo se logran esas dos +Las siguientes secciones sobre el saldo, la propiedad, el intercambio y las verificaciones detallan cómo se logran esas dos propiedades fundamentales. #### Balance Basándose en las propiedades de ECC que hemos descrito anteriormente, uno puede ocultar los valores en una transacción. -Si _v_ es el valor de una transacción de entrada o salida y _H_ una curva elíptica, podemos simplemente insertar `v*H` en -lugar de _v_ en una transacción. Esto funciona porque usando las operaciones ECC, todavía podemos validar que la suma de las +Si _v_ es el valor de una transacción de entrada o salida y _H_ una curva elíptica, podemos simplemente insertar `v*H` en +lugar de _v_ en una transacción. Esto funciona porque usando las operaciones ECC, todavía podemos validar que la suma de las salidas de una transacción es igual a la suma de las entradas: v1 + v2 = v3 => v1*H + v2*H = v3*H -Verificar esta propiedad en cada transacción permite que el protocolo verifique que una transacción no crea dinero de la -nada, sin saber cuáles son los valores reales. Sin embargo, hay un número finito de valores útiles y uno podría intentar cada -uno de ellos para adivinar el valor de su transacción. Además, conocer v1 (de una transacción anterior por ejemplo) y el -resultado `v1*H` revela todas las salidas con valor v1 a lo largo de la cadena de bloques. Por estas razones, introducimos -una segunda curva elíptica _G_ (prácticamente _G_ es sólo otro punto del generador en el mismo grupo de curvas que _H_) y una +Verificar esta propiedad en cada transacción permite que el protocolo verifique que una transacción no crea dinero de la +nada, sin saber cuáles son los valores reales. Sin embargo, hay un número finito de valores útiles y uno podría intentar cada +uno de ellos para adivinar el valor de su transacción. Además, conocer v1 (de una transacción anterior por ejemplo) y el +resultado `v1*H` revela todas las salidas con valor v1 a lo largo de la cadena de bloques. Por estas razones, introducimos +una segunda curva elíptica _G_ (prácticamente _G_ es sólo otro punto del generador en el mismo grupo de curvas que _H_) y una clave privada _r_ utilizada como *factor de ocultación*. Un valor de entrada o de salida en una operación puede expresarse como: @@ -95,7 +95,7 @@ Un valor de entrada o de salida en una operación puede expresarse como: Donde: -* _r_ es una clave privada utilizada como factor de ocultación, _G_ es una curva elíptica y su producto `r*G` es la clave +* _r_ es una clave privada utilizada como factor de ocultación, _G_ es una curva elíptica y su producto `r*G` es la clave pública para _r_ en _G_. * _v_ es el valor de una entrada o salida y _H_ es otra curva elíptica. @@ -109,7 +109,7 @@ Por ejemplo, supongamos que queremos construir una transacción con dos entradas De tal forma que: vi1 + vi2 = vo3 -Generando una clave privada como factor de ocultación para cada valor de entrada y sustituyendo cada valor por sus +Generando una clave privada como factor de ocultación para cada valor de entrada y sustituyendo cada valor por sus respectivos Compromisos de Pedersen en la ecuación anterior, obtenemos: (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vo3*H) @@ -118,7 +118,7 @@ Lo cual, requiere como consecuencia que: ri1 + ri2 = ro3 -Este es el primer pilar de Mimblewimble: la aritmética necesaria para validar una transacción se puede hacer sin conocer +Este es el primer pilar de Mimblewimble: la aritmética necesaria para validar una transacción se puede hacer sin conocer ninguno de los valores. Como nota final, esta idea se deriva en realidad de Greg Maxwell's @@ -127,32 +127,32 @@ que a su vez se deriva de una propuesta de Adam Back para valores homomórficos #### Propiedad -En la sección anterior introducimos una clave privada como factor de ocultación para cubrir los valores de la transacción. La +En la sección anterior introducimos una clave privada como factor de ocultación para cubrir los valores de la transacción. La segunda idea de Mimblewimble es que esta clave privada puede ser utilizada para probar la propiedad del valor. -Alice te envía 3 monedas y para ocultar esa cantidad, elegiste 28 como tu factor de ocultación (nota que en la práctica, -siendo el factor de ocultación una llave privada, es un número extremadamente grande). En algún lugar de la cadena de +Alice te envía 3 monedas y para ocultar esa cantidad, elegiste 28 como tu factor de ocultación (nota que en la práctica, +siendo el factor de ocultación una llave privada, es un número extremadamente grande). En algún lugar de la cadena de bloques, la siguiente salida aparece y sólo debe ser utilizable por usted: X = 28*G + 3*H _X_, el resultado de la suma, es visible para todos. El valor 3 sólo lo conocen usted y Alice, y el valor 28 sólo lo conocerá usted. -Para volver a transferir esas 3 monedas, el protocolo exige que se conozcan de alguna manera. Para demostrar cómo funciona -esto, digamos que usted quiere transferir esas 3 mismas monedas a Carol. Es necesario construir una transacción simple como +Para volver a transferir esas 3 monedas, el protocolo exige que se conozcan de alguna manera. Para demostrar cómo funciona +esto, digamos que usted quiere transferir esas 3 mismas monedas a Carol. Es necesario construir una transacción simple como esa: Xi => Y -Donde _Xi_ es una entrada que utiliza su salida _X_ e Y es la salida de Carol. No hay manera de construir tal transacción y -equilibrarla sin conocer su clave privada de 28. De hecho, si Carol va a equilibrar esta transacción, necesita saber tanto el +Donde _Xi_ es una entrada que utiliza su salida _X_ e Y es la salida de Carol. No hay manera de construir tal transacción y +equilibrarla sin conocer su clave privada de 28. De hecho, si Carol va a equilibrar esta transacción, necesita saber tanto el valor enviado como su clave privada para poder hacerlo: Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H Comprobando que todo ha sido puesto a cero, podemos asegurarnos de nuevo de que no se ha creado ningún dinero nuevo. -Espera! para! ahora ya conoces la clave privada en la salida de Carol (que, en este caso, debe ser la misma que la tuya para +Espera! para! ahora ya conoces la clave privada en la salida de Carol (que, en este caso, debe ser la misma que la tuya para equilibrarla) y así podrías robarle el dinero a Carol! Para resolver esto, Carol utiliza una clave privada de su elección. @@ -160,19 +160,19 @@ Ella escoge 113, y lo que termina en la cadena es: Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H -Ahora la transacción ya no suma cero y tenemos un _exceso de valor_ en _G_ (85), que es el resultado de la suma de todos los -factores de ocultamiento. Pero porque `85*G` es una clave pública válida en la curva elíptica _C_, con clave privada 85, para +Ahora la transacción ya no suma cero y tenemos un _exceso de valor_ en _G_ (85), que es el resultado de la suma de todos los +factores de ocultamiento. Pero porque `85*G` es una clave pública válida en la curva elíptica _C_, con clave privada 85, para cualquier x e y, sólo si `y = 0` es `x*G + y*H` una clave pública válida en _G_. -Así que todo lo que el protocolo necesita verificar es que (`Y - Xi`) es una clave pública válida en _G_ y que las partes que -realizan la transacción conocen en conjunto la clave privada (85 en nuestra transacción con Carol). La forma más sencilla de +Así que todo lo que el protocolo necesita verificar es que (`Y - Xi`) es una clave pública válida en _G_ y que las partes que +realizan la transacción conocen en conjunto la clave privada (85 en nuestra transacción con Carol). La forma más sencilla de hacerlo es requerir una firma construida con el valor excedente (85), que luego lo valida: * Las partes que realizan la transacción conocen colectivamente la clave privada, y -* La suma de las salidas de transacción, menos las entradas, suma a un valor cero (porque sólo una clave pública válida, que +* La suma de las salidas de transacción, menos las entradas, suma a un valor cero (porque sólo una clave pública válida, que coincida con la clave privada, se comprobará con la firma) -Esta firma, que se adjunta a cada transacción, junto con algunos datos adicionales (como las tasas de explotación minera), se +Esta firma, que se adjunta a cada transacción, junto con algunos datos adicionales (como las tasas de explotación minera), se denomina _transacción de kernel_ y es comprobada por todos los validadores. #### Algunos puntos más precisos @@ -182,8 +182,8 @@ Esta sección explica con más detalle la creación de transacciones discutiendo ##### Cambio -Digamos que sólo quieres enviar 2 monedas a Carol de las 3 que recibiste de Alice. Para hacer esto enviarías la moneda -restante a ti mismo como cambio. Se genera otra clave privada (digamos 12) como un factor oculto para proteger la salida de +Digamos que sólo quieres enviar 2 monedas a Carol de las 3 que recibiste de Alice. Para hacer esto enviarías la moneda +restante a ti mismo como cambio. Se genera otra clave privada (digamos 12) como un factor oculto para proteger la salida de modificación. Carol usa su propia clave privada como antes. Change output: 12*G + 1*H @@ -196,20 +196,20 @@ Y la firma se construye de nuevo con el valor excedente, 97 en este ejemplo. ##### Pruebas de recorrido -En todos los cálculos anteriores, confiamos en que los valores de las transacciones sean siempre positivos. La introducción +En todos los cálculos anteriores, confiamos en que los valores de las transacciones sean siempre positivos. La introducción de cantidades negativas sería extremadamente problemática, ya que se podrían crear nuevos fondos en cada transacción. -Por ejemplo, se podría crear una transacción con una entrada de 2 y salidas de 5 y -3 y aún así obtener una transacción bien -equilibrada, siguiendo la definición de las secciones anteriores. Esto no puede ser fácilmente detectado porque incluso si +Por ejemplo, se podría crear una transacción con una entrada de 2 y salidas de 5 y -3 y aún así obtener una transacción bien +equilibrada, siguiendo la definición de las secciones anteriores. Esto no puede ser fácilmente detectado porque incluso si _x_ es negativo, el punto correspondiente `x.H` en la curva se ve como cualquier otro. -Para resolver este problema, Mimblewimble utiliza otro concepto criptográfico (también procedente de Transacciones -Confidenciales) llamado pruebas de rango: una prueba de que un número está dentro de un rango dado, sin revelar el número. No -daremos más detalles sobre la prueba de rango, pero sólo necesitas saber que para cualquier `r.G + v.H` podemos construir una +Para resolver este problema, Mimblewimble utiliza otro concepto criptográfico (también procedente de Transacciones +Confidenciales) llamado pruebas de rango: una prueba de que un número está dentro de un rango dado, sin revelar el número. No +daremos más detalles sobre la prueba de rango, pero sólo necesitas saber que para cualquier `r.G + v.H` podemos construir una prueba que demuestre que _v_ es mayor que cero y no se sobrecarga. -También es importante tener en cuenta que para crear una prueba de rango válida a partir del ejemplo anterior, deben -conocerse tanto los valores 113 como 28 utilizados al crear y firmar el exceso de valor. La razón de ello, así como una +También es importante tener en cuenta que para crear una prueba de rango válida a partir del ejemplo anterior, deben +conocerse tanto los valores 113 como 28 utilizados al crear y firmar el exceso de valor. La razón de ello, así como una descripción más detallada de las pruebas de rango, se detallan en la sección [range proof paper](https://eprint.iacr.org/2017/1066.pdf). #### Poniendo todo junto @@ -218,22 +218,22 @@ Una transacción Mimblewimble incluye lo siguiente: * Un conjunto de entradas, que hacen referencia y consumen un conjunto de salidas anteriores. * Un conjunto de nuevos resultados que incluyen: -* Un valor y un factor oculto (que es sólo una nueva clave privada) multiplicados en una curva +* Un valor y un factor oculto (que es sólo una nueva clave privada) multiplicados en una curva y sumados para ser `r.G + v.H`. * Una prueba de rango que muestra que v no es negativo. * Una comisión explícita de transacción, en compensación.. -* Una firma, que se calcula tomando el exceso de valor oculto (la suma de todas las salidas más la tarifa, menos las +* Una firma, que se calcula tomando el exceso de valor oculto (la suma de todas las salidas más la tarifa, menos las entradas) y utilizándolo como clave privada. ### Bloques y estado de la cadena -Hemos explicado anteriormente cómo las transacciones de Mimblewimble pueden proporcionar fuertes garantías de anonimato a la -vez que mantienen las propiedades requeridas para una cadena de bloques válida, es decir, una transacción no crea dinero y la +Hemos explicado anteriormente cómo las transacciones de Mimblewimble pueden proporcionar fuertes garantías de anonimato a la +vez que mantienen las propiedades requeridas para una cadena de bloques válida, es decir, una transacción no crea dinero y la prueba de la propiedad se establece a través de claves privadas. El formato de bloques Mimblewimble se basa en esto introduciendo un concepto adicional: _cut-through_. Con esta incorporación, una cadena Mimblewimble gana: -* Extremadamente buena escalabilidad, ya que la gran mayoría de los datos de las transacciones pueden ser eliminados con el +* Extremadamente buena escalabilidad, ya que la gran mayoría de los datos de las transacciones pueden ser eliminados con el tiempo, sin comprometer la seguridad. * Mayor anonimato al mezclar y eliminar datos de transacciones. * Y la capacidad de los nuevos nodos para sincronizarse con el resto de la red de forma muy eficiente. @@ -258,20 +258,20 @@ Podemos decir que lo siguiente es cierto para cualquier transacción válida (ig sum(outputs) - sum(inputs) = kernel_excess -Lo mismo ocurre con los bloques mismos una vez que nos damos cuenta de que un bloque es simplemente un conjunto de entradas, -salidas y núcleos de transacción agregados. Podemos sumar las salidas tx, restar la suma de las entradas tx y comparar el +Lo mismo ocurre con los bloques mismos una vez que nos damos cuenta de que un bloque es simplemente un conjunto de entradas, +salidas y núcleos de transacción agregados. Podemos sumar las salidas tx, restar la suma de las entradas tx y comparar el compromiso resultante de Pedersen con la suma de los excesos del núcleo. - sum(outputs) - sum(inputs) = sum(kernel_excess) -Simplificando un poco, (de nuevo ignorando las tarifas de transacción) podemos decir que los bloques Mimblewimble pueden ser +Simplificando un poco, (de nuevo ignorando las tarifas de transacción) podemos decir que los bloques Mimblewimble pueden ser tratados exactamente como transacciones Mimblewimble. #### Kernel Offsets -Hay un problema leve con los bloques y las transacciones de Mimblewimble como se describe anteriormente. Es posible (y en -algunos casos trivial) reconstruir las transacciones constituyentes en un bloque. Esto es claramente malo para la privacidad. -Este es el problema del "subconjunto" - dado un conjunto de entradas, salidas y núcleos de transacción, un subconjunto de +Hay un problema leve con los bloques y las transacciones de Mimblewimble como se describe anteriormente. Es posible (y en +algunos casos trivial) reconstruir las transacciones constituyentes en un bloque. Esto es claramente malo para la privacidad. +Este es el problema del "subconjunto" - dado un conjunto de entradas, salidas y núcleos de transacción, un subconjunto de estos se recombinará para reconstruir una transacción válida. Por ejemplo, teniendo en cuenta las dos transacciones siguientes - @@ -283,7 +283,7 @@ Podemos agregarlos en el siguiente bloque (o transacción agregada) - (in1, in2, in3) -> (out1, out2), (kern1, kern2) -Es relativamente fácil intentar todas las permutaciones posibles para recuperar una de las transacciones +Es relativamente fácil intentar todas las permutaciones posibles para recuperar una de las transacciones (donde se suma con éxito a cero). - (in1, in2) -> (out1), (kern1) @@ -292,27 +292,27 @@ También sabemos que todo lo que queda puede ser usado para reconstruir la otra (in3) -> (out2), (kern2) -Para mitigar esto, incluimos un _kernel offset_ con cada transacción del kernel. Este es un factor oculto (clave privada) que +Para mitigar esto, incluimos un _kernel offset_ con cada transacción del kernel. Este es un factor oculto (clave privada) que debe añadirse de nuevo al exceso de núcleo para verificar que la suma de los compromisos sea cero. - sum(outputs) - sum(inputs) = kernel_excess + kernel_offset -Cuando agregamos transacciones en un bloque, almacenamos un único offset de agregados en el encabezado del bloque. Y ahora -tenemos una única compensación que no puede descomponerse en las compensaciones del núcleo de transacciones individuales y +Cuando agregamos transacciones en un bloque, almacenamos un único offset de agregados en el encabezado del bloque. Y ahora +tenemos una única compensación que no puede descomponerse en las compensaciones del núcleo de transacciones individuales y las transacciones ya no pueden reconstruirse. - sum(outputs) - sum(inputs) = sum(kernel_excess) + kernel_offset "Dividimos" la clave `k` en `k1+k2` durante la construcción de la transacción. Para una transacción kernel `(k1+k2)*G` publicamos `k1*G` (el exceso) y `k2` (el offset) y firmamos la transacción con `k1*G` como antes. -Durante la construcción del bloque podemos simplemente sumar las compensaciones `k2` para generar una sola compensación -agregada `k2` para cubrir todas las transacciones en el bloque. La compensación `k2` para cualquier transacción individual es +Durante la construcción del bloque podemos simplemente sumar las compensaciones `k2` para generar una sola compensación +agregada `k2` para cubrir todas las transacciones en el bloque. La compensación `k2` para cualquier transacción individual es imposible de recuperar. #### Cortado a medida -Los bloques permiten a los mineros ensamblar múltiples transacciones en un solo conjunto que se añade a la cadena. En las -siguientes representaciones en bloque, que contienen 3 transacciones, sólo se muestran las entradas y salidas de las -transacciones. Los ingresos hacen referencia a las salidas que gastan. Una salida incluida en un bloque anterior está marcada +Los bloques permiten a los mineros ensamblar múltiples transacciones en un solo conjunto que se añade a la cadena. En las +siguientes representaciones en bloque, que contienen 3 transacciones, sólo se muestran las entradas y salidas de las +transacciones. Los ingresos hacen referencia a las salidas que gastan. Una salida incluida en un bloque anterior está marcada con una x minúscula. I1(x1) --- O1 @@ -327,20 +327,20 @@ con una x minúscula. Observamos las dos propiedades siguientes: * Dentro de este bloque, algunas salidas son gastadas directamente por las entradas incluidas (I3 gasta O2 e I4 gasta O3). -* La estructura de cada transacción no importa realmente. Como todas las transacciones se suman individualmente a cero, la +* La estructura de cada transacción no importa realmente. Como todas las transacciones se suman individualmente a cero, la suma de todas las entradas y salidas de transacciones debe ser cero. -Al igual que en una transacción, todo lo que hay que comprobar en un bloque es que la propiedad ha sido probada (que proviene -de _núcleos de transacción_) y que todo el bloque no ha añadido ninguna cantidad de fondos (aparte de lo que permite la base +Al igual que en una transacción, todo lo que hay que comprobar en un bloque es que la propiedad ha sido probada (que proviene +de _núcleos de transacción_) y que todo el bloque no ha añadido ninguna cantidad de fondos (aparte de lo que permite la base de datos de la moneda). -Por lo tanto, se pueden eliminar las entradas y salidas que coincidan, ya que su contribución a la suma total se anula. Lo +Por lo tanto, se pueden eliminar las entradas y salidas que coincidan, ya que su contribución a la suma total se anula. Lo que conduce a los siguientes bloques, mucho más compactos: I1(x1) | O1 I2(x2) | O4 | O5 -Tenga en cuenta que se ha eliminado toda la estructura de transacciones y que el orden de las entradas y salidas ya no +Tenga en cuenta que se ha eliminado toda la estructura de transacciones y que el orden de las entradas y salidas ya no importa. Sin embargo, la suma de todas las salidas de este bloque, menos las entradas, sigue siendo cero. Un bloque se contruye simplemente a partir de: @@ -357,43 +357,43 @@ Un bloque se contruye simplemente a partir de: Con esta estructura, un bloque Mimblewimble ofrece unas garantías de privacidad muy buenas: * Las transacciones intermedias (cut-through) estarán representadas únicamente por sus núcleos de transacciones. -* Todas las salidas se ven iguales: sólo números muy grandes que son imposibles de diferenciar entre sí. Si uno quisiera +* Todas las salidas se ven iguales: sólo números muy grandes que son imposibles de diferenciar entre sí. Si uno quisiera excluir algunas salidas, tendrían que excluir todas. -* Se ha eliminado toda la estructura de la transacción, lo que hace imposible saber qué salida se correspondía con cada +* Se ha eliminado toda la estructura de la transacción, lo que hace imposible saber qué salida se correspondía con cada entrada. Y sin embargo, todo esto sigue confirmándose! #### Atravesado todo el camino -Volviendo al bloque de ejemplo anterior, las salidas x1 y x2, gastadas por I1 e I2, deben haber aparecido previamente en la -cadena de bloques. Así que después de la adición de este bloque, esas salidas, así como I1 e I2, también pueden ser +Volviendo al bloque de ejemplo anterior, las salidas x1 y x2, gastadas por I1 e I2, deben haber aparecido previamente en la +cadena de bloques. Así que después de la adición de este bloque, esas salidas, así como I1 e I2, también pueden ser eliminadas de la cadena global, ya que no contribuyen a la suma total. -Concluimos que, generalizando, el estado de la cadena (excluyendo las cabeceras) en cualquier momento puede ser resumido sólo +Concluimos que, generalizando, el estado de la cadena (excluyendo las cabeceras) en cualquier momento puede ser resumido sólo por estas piezas de información: 1. La cantidad total de monedas creadas por la minería en la cadena. 1. El conjunto completo de resultados no utilizados. 1. Los núcleos de transacciones para cada transacción. -La primera información se puede deducir simplemente usando la altura del bloque (su distancia del bloque génesis). Y tanto -las salidas no utilizadas como los núcleos de transacción son extremadamente compactos. Esto tiene dos consecuencias +La primera información se puede deducir simplemente usando la altura del bloque (su distancia del bloque génesis). Y tanto +las salidas no utilizadas como los núcleos de transacción son extremadamente compactos. Esto tiene dos consecuencias importantes: -* El estado que un nodo dado en una cadena de bloques Mimblewimble necesita mantener es muy pequeño (del orden de unos pocos +* El estado que un nodo dado en una cadena de bloques Mimblewimble necesita mantener es muy pequeño (del orden de unos pocos gigabytes para una cadena del tamaño de Bitcoin, y potencialmente configurable a unos pocos centenares de megabytes). -* Cuando un nuevo nodo se une a una red formando una cadena Mimblewimble, la cantidad de información que necesita ser +* Cuando un nuevo nodo se une a una red formando una cadena Mimblewimble, la cantidad de información que necesita ser transferida es también muy pequeña.. -Además, el conjunto completo de resultados no utilizados no puede ser alterado, ni siquiera añadiendo o quitando un -resultado. Hacerlo haría que la suma de todos los factores de ocultación en los núcleos de la transacción difiriera de la +Además, el conjunto completo de resultados no utilizados no puede ser alterado, ni siquiera añadiendo o quitando un +resultado. Hacerlo haría que la suma de todos los factores de ocultación en los núcleos de la transacción difiriera de la suma de la ocultación, factores que influyen en los resultados. ### Conclusión -En este documento tratamos los principios básicos que subyacen a una cadena de bloques Mimblewimble. Utilizando las -propiedades de suma de la Criptografía de Curva Elíptica, somos capaces de construir transacciones que son completamente -opacas pero que todavía pueden ser validadas adecuadamente. Y al generalizar esas propiedades a bloques, podemos eliminar una -gran cantidad de datos de la cadena de bloques, lo que permite una gran escalabilidad y una sincronización rápida de nuevos +En este documento tratamos los principios básicos que subyacen a una cadena de bloques Mimblewimble. Utilizando las +propiedades de suma de la Criptografía de Curva Elíptica, somos capaces de construir transacciones que son completamente +opacas pero que todavía pueden ser validadas adecuadamente. Y al generalizar esas propiedades a bloques, podemos eliminar una +gran cantidad de datos de la cadena de bloques, lo que permite una gran escalabilidad y una sincronización rápida de nuevos participantes. diff --git a/doc/intro_JP.md b/doc/translations/intro_JP.md similarity index 98% rename from doc/intro_JP.md rename to doc/translations/intro_JP.md index afec5705ed..f0b20caeec 100644 --- a/doc/intro_JP.md +++ b/doc/translations/intro_JP.md @@ -1,6 +1,6 @@ # Mimblewimble と Grin 概論 -*この文章を他の言語で読む： [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* +*この文章を他の言語で読む： [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* Mimblewimble は、極めてよいスケーラビリティ、プライバシー、そして代替可能性（fungibility）の解決法を提供 するブロックチェーンのフォーマット・プロトコルである。Mimblewimble は、ほとんどすべてのブロックチェーンの @@ -133,7 +133,7 @@ Alice があなたに 3 coin を送金し、その額を秘匿化するために X = 28*G + 3*H -加算の結果である _X_ は誰からも見ることができる。送金額 3 は Alice とあなただけが知っていて、 +加算の結果である _X_ は誰からも見ることができる。送金額 3 は Alice とあなただけが知っていて、 28 はあなただけが知っている。 この 3 coin を再び転送するには、プロトコルは 28 の値をどうにかして知っている必要がある。 @@ -178,7 +178,7 @@ _transaction kernel_ と呼ばれ、バリデーターにチェックされる #### いくつかの細かい点について -この章では、お釣りがどのように導入されるか、またすべての値が非負であることの証明となる range proof +この章では、お釣りがどのように導入されるか、またすべての値が非負であることの証明となる range proof の要件について議論することで、トランザクションの構成についての詳細を詳しく述べる。これらの両方とも、 Mimblewimble と Grin を理解するために必ず必要というわけではない。したがって、もし急いでいるのならば [まとめ](#まとめ) まで読み飛ばしてもらって構わない。 @@ -186,7 +186,7 @@ Mimblewimble と Grin を理解するために必ず必要というわけでは ##### お釣り Alice から受け取った 3 coins のうち 2 coins を Carol に送金したいとする。 -そのためには、残りの 1 coin を自らにお釣りとして送金する。もう一つの秘密鍵（12 とする）を +そのためには、残りの 1 coin を自らにお釣りとして送金する。もう一つの秘密鍵（12 とする）を blinding factor として生成しお釣りの output を保護する。Carol は以前の例と同じように 自らの秘密鍵を使用する。 diff --git a/doc/intro_KR.md b/doc/translations/intro_KR.md similarity index 96% rename from doc/intro_KR.md rename to doc/translations/intro_KR.md index afe6b3ca5f..9c88319ebb 100644 --- a/doc/intro_KR.md +++ b/doc/translations/intro_KR.md @@ -1,6 +1,6 @@ # Mimblewimble 과 Grin 에 대한 소개 -*다른 언어로 되어있는 문서를 읽으려면: [English](intro.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md), [简体中文](intro.zh-cn.md).* +*다른 언어로 되어있는 문서를 읽으려면: [English](../intro.md), [Español](intro_ES.md), [Русский](intro.ru.md), [日本語](intro.jp.md), [简体中文](intro.zh-cn.md).* MimbleWimlbe은 블록체인 포맷이면서 프로토콜 입니다. Mimblewimble은 암호학적 기반에 의해서 극대화된 좋은 확장성, 프라이버시, 그리고 대체가능성을 제공합니다. 이러한 특성은 지금 현존하는 모든 블록체인 구현체에 존재하는 문제점들을 처리합니다. @@ -13,7 +13,7 @@ Grin 프로젝트의 주요 목적과 특성들은 아래 설명을 참고하십 * Mimble Wimble 은 수십년 동안 테스트하고 사용되었던 강력한 암호기술인 ECC만 사용합니다. * 간단한 디자인은 감사와 유지보수를 시간이 지나도 수월하게 만듭니다. * 커뮤니티가 주도하며, 채굴 탈중앙화가 권장됩니다. - + ## 모두의 혀를 묶자. 이 문서는 블록체인에 대해 어느정도 이해가 있고 암호학에 대한 기본적인 이해가 있는 독자들을 대상으로 합니다. 이것을 염두에 두고 우리는 Mimblewimble의 기술적인 발전과 어떻게 Grin에 적용되었는지 관해 설명 할 것입니다. 저희는 이 문서가 대부분의 기술적인 성격을 가진 독자들을 이해시킬 수 있길 바랍니다. 우리의 목적은 독자가 Grin에 대해 흥미를 느끼게 하고 어떤 방식으로든 Grin에 기여할 수 있게 이끄는 것입니다. @@ -38,7 +38,7 @@ ECC 안에서 우리가 매우 큰 숫자인 _k_ 를 프라이빗 키로 가정 _k_ 와 _j_ 둘다 비밀키인 이전 공식 `(k+j)*H = k*H + j*H` 는 두개의 비밀키를 더해서 얻은 한 개의 공개키 (`(k+j)*H`) 와 각각 두개의 비밀키에 공개키를 더한것과 같습니다. Bitcoin blockchain에서도 HD 지갑은 이 원칙에 의존하고 있습니다. Mimblewimble 과 Grin의 구현또한 마찬가지 입니다. -### Mimblewimble 함께 거래하기 +### Mimblewimble 함께 거래하기 트랜잭션의 구조는 Mimblewimble의 강력한 프라이버시와 비밀이 유지된다라고 하는 중요한 규칙을 나타냅니다. Mimblewimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제로 합니다. @@ -79,7 +79,7 @@ Mimblewimble 트랜잭션의 확인은 두가지 기본적인 성격을 전제 vi1 + vi2 = vo3 -입니다. +입니다. 각각의 입력값에 대해서 blining factor 로 비밀키를 만들고 각각의 값을 각각의 이전의 공식에 있던 Pederson Commitment로 교체한다고 하면 다음과 같습니다. @@ -103,7 +103,7 @@ Alice는 당신에게 3 코인을 보내면서 그 양을 가렸고, 당신은 2 X = 28*G + 3*H -_X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신과 Alice만 알고 있고 28은 당신만이 알고 있습니다. +_X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신과 Alice만 알고 있고 28은 당신만이 알고 있습니다. 다시 3코인을 보내기 위해선, 프로토콜은 어떻게든 28을 알고 있어야 됩니다. 어떻게 이것이 작동하는지 보기 위해서, 당신이 캐롤에게 같은 3코인을 보내고 싶어한다고 합시다. 그렇다면 당신은 아래와 같은 간단한 트랜잭션을 작성해야 합니다. @@ -118,7 +118,7 @@ _X_ 는 덧셈의 결과이면서 모두에게 다 보여집니다. 3은 당신 Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H -입니다. +입니다. 모든계산이 0으로 되었는지 확인함으로써, 새로운 돈이 만들어지지 않았다는 것을 확인할 수 있습니다. 오 잠시만요! 당신은 지금 캐롤의 출력값에 비밀키가 있다는것을 알았습니다. ( 이런경우에는 당신의 잔액이 나간것과 동일 해야 합니다.) 그리고 당신은 캐롤로 부터 돈을 훔칠수 있습니다. 이걸 해결하기위해서 캐롤은 그녀가 선택한 비밀키를 사용합니다. @@ -191,9 +191,9 @@ MimbleWimlbe 트랜잭션은 다음을 포함합니다. * 이전의 출력값들이 참조하고 사용한 입력값의 셋트들 * 새로운 출력값의 세트들 ( Pederson commitment) * kernal execess와 (kernel 초과값이 공개키로 사용된) 트랜잭션 Signature로 이뤄진 트랜잭션 Kernel. - + sign 된 트랜잭션과 Signature 은 _transaction kernel_ 에 포함됩니다. -Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel excess_ 를 이용해서 생성됩니다. +Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel excess_ 를 이용해서 생성됩니다. (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H @@ -203,7 +203,7 @@ Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel ex 출력값의 합 - 입력값의 합 = kernel_excess -블록이 입력값과 출력값의 합 그리고 트랜잭션 kernel들의 집합이면 블록도 마찬가지라고 할 수 있습니다. 트랜잭션의 출력값을 더할 수 있고 입력값의 합을 뺀다음 그 결과인 Perderson commitment 와 kernal excess와 비교합니다. +블록이 입력값과 출력값의 합 그리고 트랜잭션 kernel들의 집합이면 블록도 마찬가지라고 할 수 있습니다. 트랜잭션의 출력값을 더할 수 있고 입력값의 합을 뺀다음 그 결과인 Perderson commitment 와 kernal excess와 비교합니다. 출력값의 합 - 입력값의 합 = kernel_excess의 합 @@ -211,11 +211,11 @@ Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel ex ##### Kernel 오프셋들 -위에 설명했던겉 처럼 Mimblewimble 블록과 트랜잭션에 조그마한 문제가 있습니다. 그것은 블록에 있는 구성 트랜잭션을 재구성하는것이 가능합다는 겁니다.(그리고 어떤 사소한 경우에도요). +위에 설명했던겉 처럼 Mimblewimble 블록과 트랜잭션에 조그마한 문제가 있습니다. 그것은 블록에 있는 구성 트랜잭션을 재구성하는것이 가능합다는 겁니다.(그리고 어떤 사소한 경우에도요). 이것은 분명히 프라이버시에는 좋지 않습니다. 이걸 "subset" 문제 라고 합니다. "Subset" 문제란 주어진 입력값들, 출력값들과 트랜잭션 kernel들의 Subset 들이 재조합되어서 유효한 트랜잭션을 다시 만든다는 것입니다. -예를 들어 다음과 같이 두 트랜잭션이 있다고 해봅시다. +예를 들어 다음과 같이 두 트랜잭션이 있다고 해봅시다. (in1, in2) -> (out1), (kern1) (in3) -> (out2), (kern2) @@ -224,7 +224,7 @@ Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel ex (in1, in2, in3) -> (out1, out2), (kern1, kern2) -(합계가 0일경우 ) 트랜잭션들 중 하나를 복구하기 위해서 가능한 모든 순열 조합을 조합해보는것은 쉽습니다. +(합계가 0일경우 ) 트랜잭션들 중 하나를 복구하기 위해서 가능한 모든 순열 조합을 조합해보는것은 쉽습니다. (in1, in2) -> (out1), (kern1) @@ -232,23 +232,23 @@ Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel ex (in3) -> (out2), (kern2) -이런것을 완화 시키기 위해 _kernel offset_ 이라는 것을 모든 트랜잭션 kernel 에 포함시킵니다. 실행 값이 0이라는 것을 증명하기 위해 kernel excess 에 더해져야 하는 blinding factor (비밀키)입니다. +이런것을 완화 시키기 위해 _kernel offset_ 이라는 것을 모든 트랜잭션 kernel 에 포함시킵니다. 실행 값이 0이라는 것을 증명하기 위해 kernel excess 에 더해져야 하는 blinding factor (비밀키)입니다. 출력값의 합 - 입력값의 합 = kernel_excess + kernel 오프셋(offset) -블록 안에서 트랜잭션을 합칠때, _single_ 통합 오프셋(offset)을 블록 헤더에 저장합니다. +블록 안에서 트랜잭션을 합칠때, _single_ 통합 오프셋(offset)을 블록 헤더에 저장합니다. 그래서 single 오프셋으로 인해 개별 트랜잭션 kernel offset 을 개별로 분리할 수 없고 트랜잭션 들은 더이상 재구성 될 수 없습니다. 출력값의 합 - 입력값의 합 = kernel_excess의 합 + kernel_offset -키 `k`를 트랜잭션 구성 중에 `k1+k2` 안에 나누어서 넣었습니다. 트랜잭션 커널인`(k1+k2)*G` 에 대해 excess 인 `k1*G`와 오프셋(offset) 인 `k2`를 보여주고 이전처럼 `k1*G`로 트랜잭션에 sign 합니다. +키 `k`를 트랜잭션 구성 중에 `k1+k2` 안에 나누어서 넣었습니다. 트랜잭션 커널인`(k1+k2)*G` 에 대해 excess 인 `k1*G`와 오프셋(offset) 인 `k2`를 보여주고 이전처럼 `k1*G`로 트랜잭션에 sign 합니다. -블록을 만드는 동안 블록안의 모든 트랜잭션을 커버하기 위한 한개의 통합 `k` 오프셋을 만들기 위해 `k2`오프셋을 간단히 합할 수 있습니다. `k2`오프셋은 어떤 개별 트랜잭션이 복구되지 못하도록 합니다. +블록을 만드는 동안 블록안의 모든 트랜잭션을 커버하기 위한 한개의 통합 `k` 오프셋을 만들기 위해 `k2`오프셋을 간단히 합할 수 있습니다. `k2`오프셋은 어떤 개별 트랜잭션이 복구되지 못하도록 합니다. #### 컷 스루 (Cut-through) - + 블록들은 채굴자들이 여러 트랜잭션들을 하나의 세트에 넣고 체인에 더할수 있게 합니다. -다음 블록은 3개의 트랜잭션을 포함하고 있습니다. 오직 입력과 출력만을 보여줍니다. +다음 블록은 3개의 트랜잭션을 포함하고 있습니다. 오직 입력과 출력만을 보여줍니다. 소비한 출력값은 입력값을 참고 합니다. 출력값은 소문자 x로 표시된 이전 블록을 포함합니다. I1(x1) --- O1 @@ -266,23 +266,23 @@ Signature 공개키로서 트랜잭션의 합이 0임을 증명하는 _kernel ex 트랜잭션과 비슷하게 블록에서 체크해야 되는 것은 _transaction kernels_ 에서 비롯되는 소유권의 증명과 coinbase 에서 증가하는 코인 외 모든 블록이 돈의 공급을 추가하지 않았다는 것입니다. 매칭된 값은 전체의 값을 상쇄하므로 매치되는 입력값과 출력값은 없앨 수 있고 다음과 같이 좀 더 작은 블록이 됩니다. - + I1(x1) | O1 I2(x2) | O4 | O5 -모든 트랜잭션 구조는 다 제거되었고 입력값과 출력값의 순서는 더이상 중요하지 않습니다. -그러나 블록에서 입력값을 뺸 모든 출력값의 합은 여전히 0임을 보증합니다. +모든 트랜잭션 구조는 다 제거되었고 입력값과 출력값의 순서는 더이상 중요하지 않습니다. +그러나 블록에서 입력값을 뺸 모든 출력값의 합은 여전히 0임을 보증합니다. -블록은 아래와 간단히 말하자면 아래를 포함합니다. +블록은 아래와 간단히 말하자면 아래를 포함합니다. * 블록헤더 * 컷 스루 이후 남은 입력값의 리스트 * 컷 스루 이후 남은 출력값의 리스트 -* 모든 블록을 커버하기 위한 단일 kernel offset +* 모든 블록을 커버하기 위한 단일 kernel offset * 트랜잭션 kernel들은 각 트랜잭션에 아래와 같은 것들을 포함합니다. * The public key `r*G` obtained from the summation of all the commitments. - * 모든 커밋들의 합을 포함한 공개키 `r*G` + * 모든 커밋들의 합을 포함한 공개키 `r*G` * 초과값 (excess value) 을 이용해 생성된 Signature * 채굴 수수료 diff --git a/doc/intro_NL.md b/doc/translations/intro_NL.md similarity index 98% rename from doc/intro_NL.md rename to doc/translations/intro_NL.md index 9978b2dce7..84e76c3ea6 100644 --- a/doc/intro_NL.md +++ b/doc/translations/intro_NL.md @@ -1,6 +1,6 @@ # Inleiding tot Mimblewimble en Grin -*Lees dit in andere talen: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* +*Lees dit in andere talen: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* Mimblewimble is een blockchain formaat en protocol die extreem goede schaalbaarheid, privacy en fungibiliteit biedt door zich te berusten op sterke cryptografische primiteven. Het adresseert de lacunes die in bijna alle huidige blockchain-implementaties bestaan. @@ -22,7 +22,7 @@ Het belangrijkste doel en eigenschappen van het Grin project zijn: controleren en onderhouden. * Gemeenschapsgedreven, met behulp van een asic-resistant mining algoritme (Cuckoo Cycle) welke mining decentralisatie stimuleert. - + ## Betwisting voor Iedereen Dit document is bedoeld voor lezers met een sterke achtergrond @@ -65,8 +65,8 @@ terwijl vermenigvuldiging triviaal is, "verdeling" door curvepunten is extreem m De vorige formule `(k+j)*H = k*H + j*H`, met _k_ en _j_ als privésleutels, demonstreert dat een openbare sleutel verkregen is door de toevoeging van twee privésleutels (`(k+j)*H`) zijn identiek aan de toevoeging van de -openbare sleutels voor elk van die twee privésleutels (`k*H + j*H`). -In de Bitcoin blockchain, zijn Hiërarchische Deterministische portefeuilles +openbare sleutels voor elk van die twee privésleutels (`k*H + j*H`). +In de Bitcoin blockchain, zijn Hiërarchische Deterministische portefeuilles sterk afhankelijk van dit principe. Alsook Mimblewimble en de Grin-implementatie. ### Transacties met Mimblewimble @@ -247,7 +247,7 @@ Het is ook belangrijk om op te merken dat om een geldige range proof te maken ui Een Mimblewimble transactie omvat het volgende: -* Een reeks invoeren, die verwijzen naar en een vorige reeks aan uitvoeren spendeert. +* Een reeks invoeren, die verwijzen naar en een vorige reeks aan uitvoeren spendeert. * Een reeks van nieuwe uitvoeren met: * Een waarde en een blinding factor (welke gewoonweg een nieuwe privésleutel is) vermenigvuldigd met een curve en bij elkaar opgeteld `r.G + v.H`. @@ -288,7 +288,7 @@ We kunnen zeggen dat het volgende waar is voor elke geldige transactie (voor een som(uitvoeren) - som(invoeren) = kernel_excess -Hetzelfde geldt voor blokken zelf als we eenmaal realiseren dat een blok eenvoudigweg een reeks van geaggregeerde invoeren, uitvoeren en transactiekernels zijn. +Hetzelfde geldt voor blokken zelf als we eenmaal realiseren dat een blok eenvoudigweg een reeks van geaggregeerde invoeren, uitvoeren en transactiekernels zijn. som(uitvoeren) - som(invoeren) = sum(kernel_excess) @@ -324,7 +324,7 @@ Wanneer we transacties in een blok samenvoegen, bewaren we een _single_ geaggreg som(uitvoeren) - sum(invoeren) = sum(kernel_excess) + kernel_offset We "splitsen" de sleutel `k` in `k1+k2` tijdens de transactie opbouw. Voor een transactie kernel `(k1+k2)*G` publiceren we `k1*G` (de overspil) en `k2` (de offset) en ondertekenen we de transactie met `k1*G` zoals eerder. -Tijdens de blockconstructie kunnen we eenvoudigweg de `k2` offsets optellen om een single aggregate `k2` offset te genereren om alle transacties in de blok te dekken. De `k2` offset voor elke individuele transactie is niet-terugvorderbaar. +Tijdens de blockconstructie kunnen we eenvoudigweg de `k2` offsets optellen om een single aggregate `k2` offset te genereren om alle transacties in de blok te dekken. De `k2` offset voor elke individuele transactie is niet-terugvorderbaar. #### Cut-through @@ -393,7 +393,7 @@ samengevat kunnen worden door alleen deze stukjes informatie: 1. De volledige verzameling aan niet-bestede uitgaven. 1. De transactiekernels voor elke transactie. -Het eerste stuk informatie kan afgeleid worden door alleen de blokhoogte +Het eerste stuk informatie kan afgeleid worden door alleen de blokhoogte (de afstand tot het genesisblok) te gebruiken. En zowel de niet-bestede uitgaven als de transactiekernels zijn ontzettend compact. Dit heeft 2 belangrijke gevolgen: diff --git a/doc/intro_PT-BR.md b/doc/translations/intro_PT-BR.md similarity index 98% rename from doc/intro_PT-BR.md rename to doc/translations/intro_PT-BR.md index 392a178128..ee6a052081 100644 --- a/doc/intro_PT-BR.md +++ b/doc/translations/intro_PT-BR.md @@ -1,6 +1,6 @@ # Introdução ao Mimblewimble e ao Grin -*Leia isto em outros idiomas: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* +*Leia isto em outros idiomas: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* O Mimblewimble é um formato e protocolo blockchain que fornece ótima escalabilidade, privacidade e fungibilidade, para isso contando com primitivas criptográficas fortes. Ele aborda as lacunas existentes em quase todos as implementações blockchain atuais. @@ -288,4 +288,3 @@ Além disso, o conjunto completo de saídas não gastas não pode ser adulterado ### Conclusão Neste documento, cobrimos os princípios básicos subjacentes a um blockchain Mimblewimble. Usando as propriedades de adição da Criptografia de Curva Elíptica, construímos transações completamente opacas, mas que ainda assim podem ser corretamente validadas. E ao generalizar essas propriedades em blocos, podemos eliminar uma grande quantidade de dados do blockchain, permitindo uma grande escalabilidade bem como a rápida sincronização de novos pares. - diff --git a/doc/intro_RU.md b/doc/translations/intro_RU.md similarity index 97% rename from doc/intro_RU.md rename to doc/translations/intro_RU.md index 1efb818547..78f7827e0f 100644 --- a/doc/intro_RU.md +++ b/doc/translations/intro_RU.md @@ -1,6 +1,6 @@ # Введение в МимблВимбл и Grin -*На других языках: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* +*На других языках: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* МимблВимбл это формат и протокол блокчейна, предоставляющий исключительную масштабируемость, приватность и обезличенность криптовалюты, @@ -45,7 +45,7 @@ Grin это проект с открытым исходным кодом, реа рассмотрев свойства, необходимые для понимания работы МимблВимбла без излишнего погружения в тонкости данного вида криптографии. -Эллиптическая Кривая это просто большое множество точек, которые мы назовём _C_. +Эллиптическая Кривая это просто большое множество точек, которые мы назовём _C_. Эти точки можно складывать, вычитать или умножать на целые числа (так же называемые скалярами). Пусть _k_ является целым числом, тогда, используя скалярное умножение, мы можем вычислить `k*H`, что так же является точкой на кривой _C_. Пусть дано другое целое число _j_, @@ -59,9 +59,9 @@ Grin это проект с открытым исходным кодом, реа тогда произведение `k*H` станет соответствующим открытым ключом. Даже если кто-то знает значение открытого ключа `k*H`, вычисление _k_ близко к невозможному (другими словами, несмотря на тривиальность умножения, деление точек Эллиптической Кривой является -крайне сложным). +крайне сложным). -Предыдущая формула `(k+j)*H = k*H + j*H`, где _k_ и _j_ хранятся в тайне, +Предыдущая формула `(k+j)*H = k*H + j*H`, где _k_ и _j_ хранятся в тайне, показывает, что открытый ключ может быть получен путём сложения двух закрытых ключей и является идентичным сложению двух соответствующих открытых ключей. Например, в Биткоин работа Детерминистических Иерархичных (HD wallets) кошельков всецело @@ -80,13 +80,13 @@ Grin это проект с открытым исходным кодом, реа выходами транзакции гарантируется владением закрытого ключа. Однако доказательство того, что некто владеет закрытым ключом, достигается иначе, нежели простой подписью транзакции. -Далее будет рассказано, как вычисляется баланс кошелька, +Далее будет рассказано, как вычисляется баланс кошелька, проверяется владение, образуется "сдача" и будет показано, как перечисленные выше свойства достигаются. #### Баланс -Основываясь на свойствах Эллиптических Кривых (ЭК), некто может сокрыть +Основываясь на свойствах Эллиптических Кривых (ЭК), некто может сокрыть количество отправляемых монет в транзакции. Пусть _v_ это значение входа или выхода транзакции и _H_ это Эллиптическая Кривая, тогда @@ -100,8 +100,8 @@ Grin это проект с открытым исходным кодом, реа что транзакция не создаёт новые монеты из воздуха, при этом не раскрывая количества передаваемых в транзакциях монет. -Однако, количество пригодных для использования количеств монет конечно и злоумышленник может -попытаться угадать передаваемое количество монет путём перебора. Кроме того, знание _v1_ +Однако, количество пригодных для использования количеств монет конечно и злоумышленник может +попытаться угадать передаваемое количество монет путём перебора. Кроме того, знание _v1_ (например из предыдущей транзакции) и конечного значения `v1*H`, раскрывает значения всех выходов всех транзакций, которые используют _v1_. Из-за этого мы введём вторую Эллиптическую Кривую _G_ (на самом деле _G_ это просто ещё один генератор группы, образованной той же самой кривой _H_) @@ -142,19 +142,19 @@ Grin это проект с открытым исходным кодом, реа Это первый из столпов МимблВимбла: вычисления, требуемые для валидации транзакции, могут быть совершены без раскрытия количеств монет, передаваемых этими транзакциями. -Примечательно, что эта идея была выведена из +Примечательно, что эта идея была выведена из [Конфиденциальных Транзакций](https://elementsproject.org/features/confidential-transactions/investigation) Грега Максвелла, которые, в свою очередь, сами основаны на предложении Адама Бэка для гомоморфных значений, применимых к Биткоину. #### Владение -Выше мы ввели закрытый ключ в качестве фактора сокрытия, чтобы сокрыть информацию о -количестве передаваемых транзакцией монет. Вторая идея, которую предоставляет МимблВимбл, это +Выше мы ввели закрытый ключ в качестве фактора сокрытия, чтобы сокрыть информацию о +количестве передаваемых транзакцией монет. Вторая идея, которую предоставляет МимблВимбл, это то, что этот же самый ключ может использоваться для доказательства владения монетами. Алиса отправляет вам 3 монеты и, чтобы сокрыть количество, вы выбрали 28 как ваш -фактор сокрытия (заметим, что на практике фактор сокрытия, будучи закрытым ключом, +фактор сокрытия (заметим, что на практике фактор сокрытия, будучи закрытым ключом, является очень большим числом). Тогда где-то в блокчейне должен быть следующий выход (UTXO), доступный для траты только вами: @@ -185,7 +185,7 @@ Grin это проект с открытым исходным кодом, реа Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H -Эта сумма (транзакция) больше не сводится к нулю и мы имеем _избыточное_ значение на _G_ (85), +Эта сумма (транзакция) больше не сводится к нулю и мы имеем _избыточное_ значение на _G_ (85), которое является результатом сложения всех факторов сокрытия. Но из-за того, что произведение `85*G` будет являться корректным открытым ключом на ЭК _C_ с приватным ключом 85, для любого x и y, только если `y = 0`, сумма `x*G + y*H` будет являться открытым ключом на _G_. @@ -198,20 +198,20 @@ Grin это проект с открытым исходным кодом, реа * Участники транзакции совместно знают закрытый ключ, и * Сумма выходов транзакции минус сумма входов, равняется нулю (потому что только валидный открытый ключ будет удовлетворять этой подписи) - -Эта подпись, прикрепляемая к каждой транзакции, совместно с некоей дополнительной информацией + +Эта подпись, прикрепляемая к каждой транзакции, совместно с некоей дополнительной информацией (например комиссиями майнеров) называется _ядром транзакции_ и должна проверяться всеми валидаторами. #### Некоторые Уточнения -Этот раздел уточняет процесс создания транзакций, обсудив то, как образуется -"сдача" и требования для доказательств неотрицательности значений. Ничего из этого не +Этот раздел уточняет процесс создания транзакций, обсудив то, как образуется +"сдача" и требования для доказательств неотрицательности значений. Ничего из этого не требуется для понимания МимблВимбла и Grin, так что если вы спешите, можете спокойной переходить к разделу [Всё Вместе](#всё-вместе). ##### Сдача -Допустим вы хотите отправить 2 монеты Кэрол из трёх монет, которые вы получили от +Допустим вы хотите отправить 2 монеты Кэрол из трёх монет, которые вы получили от Алисы. Чтобы это сделать, вы отправите остаток из 1 монеты назад к себе в качестве сдачи. Для этого создайте другой закрытый ключ (например 12) в качестве фактора сокрытия, чтобы защитить ваш выход сдачи. Кэрол использует свой закрытый ключ как и ранее. @@ -219,7 +219,7 @@ Grin это проект с открытым исходным кодом, реа Выход для сдачи: 12*G + 1*H Выход для Кэрол: 113*G + 2*H -Тогда в блокчейн попадёт кое-что уже нам знакомое, а подпись опять-таки построена +Тогда в блокчейн попадёт кое-что уже нам знакомое, а подпись опять-таки построена на избыточном значении, 97 в этом примере. (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H @@ -232,7 +232,7 @@ Grin это проект с открытым исходным кодом, реа Например, можно создать транзакцию со входом в 2 монеты и выходами 5 и -3 монет и всё равно получить хорошо сбалансированную транзакцию, согласно формулам выше. -Такие случаи будет трудно обнаруживать, поскольку даже если _x_ отрицательно, +Такие случаи будет трудно обнаруживать, поскольку даже если _x_ отрицательно, соответствующая точка `x*H` на ЭК является неотличимой от любых других. Для решения этой проблемы МимблВимбл применяет другую криптографическую идею, @@ -299,7 +299,7 @@ range proof-ов можно найти в [публикации о range proof- сумма(выходы) - сумма(входы) = сумма(избытки_ядер) -Простыми словами, с блоками МимблВимбла можно работать точно так же, как и с транзакциями МимблВимбла. +Простыми словами, с блоками МимблВимбла можно работать точно так же, как и с транзакциями МимблВимбла. ##### Смещения Ядер @@ -336,7 +336,7 @@ range proof-ов можно найти в [публикации о range proof- сумма(выходы) - сумма(входы) = сумма(избыток_ядра) + смещение_ядра -Мы "разделим" ключ `k` в сумму `k1+k2` в ходе создания транзакции. Для ядра транзакции `(k1+k2)*G` +Мы "разделим" ключ `k` в сумму `k1+k2` в ходе создания транзакции. Для ядра транзакции `(k1+k2)*G` мы оставляем открытыми `k1*G` (избыток) и `k2` (смещение) и подписываем транзакцию используя `k1*G` как раньше. В ходе сборки блока мы можем просто просуммировать смещения ядер для создания одного агрегированого смещения, покрывающего все транзакции в блоке. Смещения каждой отдельно взятой транзакции теперь невозможно восстановить. @@ -359,9 +359,9 @@ range proof-ов можно найти в [публикации о range proof- Можно обнаружить следующие два свойства: -* Внутри этого блока некоторые выходы напрямую тратятся некоторыми из входов +* Внутри этого блока некоторые выходы напрямую тратятся некоторыми из входов (I3 тратит O2 и I4 тратит O3). -* Структура каждой транзакции не имеет особого значения. Так как все транзакции +* Структура каждой транзакции не имеет особого значения. Так как все транзакции суммируются в ноль, сумма всех входов и выходов должна быть нулевой. Схожим с транзакциями образом, все, что нужно проверить в блоке, так это то, что @@ -387,7 +387,7 @@ range proof-ов можно найти в [публикации о range proof- * Открытый ключ `r*G`, полученный из суммирования всех *обязательств*. * Подпись, сгенерированная из *избыточного значения*. * Комиссия. - + Организованные таким образом блоки МимблВимбла могут предложить исключительные гарантии приватности: * Промежуточные транзакции (прорезанные) представляются только их *ядрами*. @@ -401,7 +401,7 @@ range proof-ов можно найти в [публикации о range proof- Возвращаясь к блоку из примера выше, выходы x1 и x2, потраченные входами I1 и I2, должны ранее уже находиться в блокчейне. Таким образом, после добавления этого блока, -и входы и выходы могут быть убраны из всей цепочки, так как они более не имеют вклада в общую сумму. +и входы и выходы могут быть убраны из всей цепочки, так как они более не имеют вклада в общую сумму. Обобщая, мы можем заключить, что состояние цепочки (за вычетом заголовков) в любое время может быть сведено к следующей информации: @@ -419,7 +419,7 @@ range proof-ов можно найти в [публикации о range proof- масштабов блокчейна Биткойна и потенциально оптимизируемый до нескольких сотен мегабайт. * Можно передавать очень мало информации для синхронизации новых участников сети. -В дополнение скажем, что подделать набор непотраченых выходов невозможно, поскольку +В дополнение скажем, что подделать набор непотраченых выходов невозможно, поскольку любое, даже самое маленькое изменение, вызовет расхождение между суммой факторов сокрытия из ядер транзакций и суммой факторов сокрытия из выходов транзакций. diff --git a/doc/intro_SE.md b/doc/translations/intro_SE.md similarity index 96% rename from doc/intro_SE.md rename to doc/translations/intro_SE.md index ed20cf8a14..fcd00f3fae 100644 --- a/doc/intro_SE.md +++ b/doc/translations/intro_SE.md @@ -1,6 +1,6 @@ # Introduktion till Mimblewimble och Grin -*Läs detta på andra språk: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* +*Läs detta på andra språk: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md), [简体中文](intro_ZH-CN.md).* Mimblewimble är ett blockkedjeformat och protokoll som erbjuder extremt bra skalbarhet, integritet, och fungibilitet genom starka kryptografiska primitiver. @@ -13,9 +13,9 @@ Grin-projektets huvudsakliga mål och kännetecken är: * Integritet som standard. Detta möjliggör fullkomlig fungibilitet utan att förhindra förmågan att selektivt uppdaga information efter behov. -* Växer mestadels med antal användare och minimalt med antal transaktioner (< 100 bytes transaktionskärna), +* Växer mestadels med antal användare och minimalt med antal transaktioner (< 100 bytes transaktionskärna), vilket resulterar i stora utrymmesbesparingar i jämförelse med andra blockkedjor. -* Stark och bevisad kryptografi. Mimblewimble förlitar sig endast på kryptografi med +* Stark och bevisad kryptografi. Mimblewimble förlitar sig endast på kryptografi med elliptiska kurvor (ECC) vilket har beprövats i decennier. * Simplistik design som gör det enkelt att granska och underhålla på lång sikt. * Gemenskapsdriven, uppmuntrar mining och decentralisering. @@ -47,7 +47,7 @@ heltal _j_ kan vi också beräkna `(k+j)*H`, vilket är lika med `k*H + j*H`. Ad kurvor behåller sina kommutativa och associativa egenskaper från vanlig addition och multiplikation: (k+j)*H = k*H + j*H - + Om vi inom ECC väljer ett väldigt stort tal _k_ som privat nyckel så anses `k*H` vara dess publika nyckel. Även om man vet värdet av den publika nyckeln `k*H`, är det nästintill omöjligt att härleda `k` (sagt med andra ord, medan multiplikation med kurvpunkter är trivialt är "division" extremt svårt). @@ -64,7 +64,7 @@ starka garantier av integritet och konfidentialitet. Valideringen av Mimblewimble-transaktioner använder sig av två grundläggande egenskaper: -* **Kontroll av nollsummor.** Summan av outputs minus inputs är alltid lika med noll, vilket bevisar—utan att +* **Kontroll av nollsummor.** Summan av outputs minus inputs är alltid lika med noll, vilket bevisar—utan att avslöja beloppen—att transaktionen inte skapade nya pengar. * **Innehav av privata nycklar.** Som med de flesta andra kryptovalutor garanteras ägandet av outputs (UTXOs) med innehavet av privata nycklar. Dock bevisas inte ägandet av dem genom en direkt signering av transaktionen. @@ -80,7 +80,7 @@ Om _v_ är beloppet av en input eller output och _H_ en punkt på den elliptiska lika med summan av inputs i en transaktion med hjälp av ECC-operationer: v1 + v2 = v3 => v1*H + v2*H = v3*H - + Bekräftandet av denna egenskap på alla transaktioner låter protokollet bekräfta att en transaktion inte skapar pengar ur tomma intet utan att veta vad beloppen är. Dock finns det ett begränsat antal av användbara belopp och man skulle kunna prova varenda en för att gissa beloppet på transaktionen. Dessutom, om man känner till _v1_ (till exempel från en föregående @@ -90,7 +90,7 @@ anledningar introducerar vi en andra punkt _G_ på samma elliptiska kurva och en En input eller output i en transaktion kan uttryckas som: r*G + v*H - + Där: * _r_ är en privat nyckel använd som en förblindningsfaktor, _G_ är en punkt på elliptiska kurvan _C_, och deras @@ -110,16 +110,16 @@ Vi har (utan hänsyn till avgifter): Sådana att: vi1 + vi2 = vo3 - + Vi genererar en privat nyckel som en förblidningsfaktor för varje input och ersätter alla belopp med deras respektive Pedersen Commitment och får därmed: (ri1*G + vi1*H) + (ri2*G + vi2*H) = (ro3*G + vi3*H) - + Vilket som följd kräver att: ri1 + ri2 = ro3 - + Detta är Mimblewimbles första pelare: de beräkningar som är nödvändiga för att validera en transaktion kan göras utan att veta några belopp. @@ -136,7 +136,7 @@ Alice skickar 3 mynt till dig och för att dölja beloppet väljer du 28 som din är ett extremt stort tal). Någonstans i blockkedjan dyker följande output upp och ska endast kunna spenderas av dig: X = 28*G + 3*H - + _X_ som är summan är synlig för alla. Beloppet 3 är endast känt av dig och Alice, och 28 är endast känt av dig. @@ -144,13 +144,13 @@ För att skicka dessa 3 mynt igen kräver protokollet att 28 ska vara känt. Fö oss säga att du vill skicka samma 3 mynt till Carol. Du behöver skapa en simpel transaktion sådan att: Xi => Y - + Där _Xi_ är en input som spenderar din _X_-output och Y är Carols output. Det finns inget sätt att skapa en sådan transaktion utan att känna till din privata nyckel 28. Om Carol ska balansera denna transaktion behöver hon både känna till det skickade beloppet och din privata nyckel så att: Y - Xi = (28*G + 3*H) - (28*G + 3*H) = 0*G + 0*H - + Genom att kontrollera att allt har nollställts kan vi återigen försäkra oss om att inga nya pengar har skapats. Vänta! Stopp! Nu känner du till den privata nyckeln i Carols output (vilket i detta fall måste vara samma som ditt @@ -160,7 +160,7 @@ För att lösa detta problem använder Carol en privat nyckel som hon väljer sj Det som hamnar i blockkedjan är: Y - Xi = (113*G + 3*H) - (28*G + 3*H) = 85*G + 0*H - + Nu summeras transaktionen inte längre till noll och vi har ett _överskottsbelopp_ (85), vilket är resultatet av summeringen av alla förblindningsfaktorer. Eftersom `85*G` är en giltig publik nyckel för generatorpunkt _G_ vet vi att alla inputs och outputs har balanserats och transaktionen därmed är giltig då `x*G + y*H` är en giltig publik nyckel för generatorpunkt _G_ om och endast om `y = 0`. @@ -189,12 +189,12 @@ förblindningsfaktor för att skydda beloppet på din växel-output. Carol anvä Växel-output: 12*G + 1*H Carols output: 113*G + 2*H - + Det som hamnar i blockkedjan är något väldigt likt det vi hade tidigare, och signaturen är återigen skapat med överskottsbeloppet, 97 i detta exempel. (12*G + 1*H) + (113*G + 2*H) - (28*G + 3*H) = 97*G + 0*H - + #### Range Proofs I alla beräkningar ovan förlitar vi oss på att alla belopp är positiva. Introduktionen av negativa belopp skulle vara @@ -213,12 +213,12 @@ Det är även viktigt att notera att range proofs krävs för både förblindnin Carols UTXO: 133*G + 2*H Attackerarens output: (113 + 99)*G + 2*H - + vilket kan signeras av attackeraren eftersom Carols förblindningsfaktor nollställs i ekvationen `Y - Xi`: Y - Xi = ((113 + 99)*G + 2*H) - (113*G + 2*H) = 99*G - -Denna output (`(113 + 99)*G + 2*H`) kräver att både talen 113 och 99 är kända för att kunna spenderas; attackeraren skulle därmed ha lyckats låsa Carols UTXO. Kravet på range proof för förblindingsfaktorn förhindrar detta eftersom attackeraren inte känner till 113 och därmed inte heller (113 + 99). En mer utförlig beskrivning av range proofs är förklarat i + +Denna output (`(113 + 99)*G + 2*H`) kräver att både talen 113 och 99 är kända för att kunna spenderas; attackeraren skulle därmed ha lyckats låsa Carols UTXO. Kravet på range proof för förblindingsfaktorn förhindrar detta eftersom attackeraren inte känner till 113 och därmed inte heller (113 + 99). En mer utförlig beskrivning av range proofs är förklarat i [range proof-pappret](https://eprint.iacr.org/2017/1066.pdf). #### Sammanställningen av allt @@ -231,7 +231,7 @@ En Mimblewimble-transaktion inkluderar följande: till att bli `r*G + v*H`. * Ett range proof som bland annat visar att v är icke-negativt. * En transaktionsavgift i klartext. -* En signatur vars privata nyckel beräknas genom att ta överskottsbeloppet (summan av alla outputs och +* En signatur vars privata nyckel beräknas genom att ta överskottsbeloppet (summan av alla outputs och avgiften minus inputs). ### Block och kedjetillstånd @@ -241,7 +241,7 @@ upprätthåller egenskaperna för en giltig blockkedja, d v s att en transaktion fastställs med privata nycklar. Mimblewimble-blockformatet bygger på detta genom att introducera ett till koncept: _cut-through_. Med detta -får en Mimblewimble-kedja: +får en Mimblewimble-kedja: * Extremt bra skalbarhet då den stora majoriteten av transaktionsinformation kan elimineras på lång sikt utan att kompromissa säkerhet. @@ -254,25 +254,25 @@ Kom igåg att en transaktion består av följande: * En mängd inputs som refererar till och spenderar en mängd föregående outputs * En mängd nya outputs * En transaktionskärna som består av: - * kärnöverskottet (överskottsbeloppets publika nyckel) + * kärnöverskottet (överskottsbeloppets publika nyckel) * transaktionssignatur vars publika nyckel är kärnöverskottet - + En transaktion valideras genom att kärnöverskottet faställs vara en giltig publik nyckel: (42*G + 1*H) + (99*G + 2*H) - (113*G + 3*H) = 28*G + 0*H - + Den publika nyckeln i detta exempel är `28*G`. Vi kan säga att följande är sant för alla giltiga transaktioner (vi ignorerar avgifter för enkelhetens skull): (summan av outputs) - (summan av inputs) = kärnöverskott - + Detsamma gäller för blocken själva när vi inser att ett block helt enkelt är en mängd aggregerade inputs, outputs, och transaktionskärnor. Vi kan summera alla outputs, subtrahera det med summan av alla inputs, och likställa vårt resulterande Pedersen commitment med summan av kärnöverskotten: (summan av outputs) - (summan av inputs) = (summan av kärnöverskott) - - + + Något förenklat (återigen utan hänsyn till transaktionsavgifter) kan vi säga att Mimblewimble-block kan betraktas precis som Mimblewimble-transaktioner. @@ -287,27 +287,27 @@ Betrakta dessa två transaktioner: (input1, input2) -> (output1), (kärna1) (input3) -> (output2), (kärna2) - + Vi kan aggregera dem till följande block: (input1, input2, input3) -> (output1, output2), (kärna1, kärna2) - + Det är trivialt att testa alla möjliga kombinationer och återskapa en av transaktionerna (där summan lyckas bli noll). (input1, input2) -> (output1), (kärna1) - + Vi vet också att allt som kvarstår kan användas för att rekonstruera den andra giltiga transaktionen: (input3) -> (output2), (kärna2) - + Kom ihåg att kärnöverskottet `r*G` helt enkelt är den publika nyckeln till överskottsbeloppet *r*. För att lösa detta problem omdefinierar vi kärnöverskottet från `r*G` till `(r-kärn_offset)*G` och distribuerar detta *kärn-offset* för att inkluderas i varje transktionskärna. Detta kärn-offset är således en förblindningsfaktor som måste tilläggas överskottsbeloopet för att ekvationen ska gå ihop: (summan av outputs) - (summan av inputs) = r*G = (r-kärn_offset)*G + kärn_offset*G - + eller alternativt (summan av outputs) - (summan av inputs) = kärnöverskott + kärn_offset*G - + För ett commitment `r*G + 0*H` med kärn-offset *a*, signeras transaktionen med `(r-a)` och *a* publiceras så att `r*G` kan beräknas för att kontrollera att transaktionen är giltig. Vid block-konstruktionen summeras alla kärn-offsets till ett enstaka sammanlagt offset som täcker hela blocket. Kärn-offsetet för en individuell transaktion blir därmed omöjlig att härleda och delmängdsproblemet är löst. (summan av outputs) - (summan av inputs) = (summan av kärnöverskott) + kärn_offset*G @@ -320,13 +320,13 @@ föregående outputs som härmed spenderas. Föregående outputs markeras med _x I1(x1) --- O1 |- O2 - + I2(x2) --- O3 I3(O2) -| I4(O3) --- O4 |- O5 - + Vi lägger märke till följande två egenskaper: * Inom detta block är vissa outputs spenderade direkt av påföljande inputs (I3 spenderar O2, och I4 spenderar O3). @@ -340,7 +340,7 @@ deras sammansatta påverkan är noll. Detta leder till följande, mycket mer kom I1(x1) | O1 I2(x2) | O4 | O5 - + Notera att all transaktionsstruktur har eliminerats och att ordningen av inputs och outputs inte längre spelar någon roll. Summan av alla inputs och outputs är garanterat fortfarande noll. @@ -354,7 +354,7 @@ Ett block består av: * Publika nyckeln `r*G` erhållen genom summation av alla inputs och outputs. * Signaturen genererad av överskottsbeloppet. * Mining-avgiften - + Med denna struktur erbjuder ett Mimblewimble-block extremt bra integritetsgarantier: * Mellanliggande (genomskurna) transaktioner är endast representerade av sina transaktionskärnor. diff --git a/doc/intro_ZH-CN.md b/doc/translations/intro_ZH-CN.md similarity index 98% rename from doc/intro_ZH-CN.md rename to doc/translations/intro_ZH-CN.md index 45b2171f52..490f90abfa 100644 --- a/doc/intro_ZH-CN.md +++ b/doc/translations/intro_ZH-CN.md @@ -1,7 +1,7 @@ Mimblewimble 和 Grin 简介 ===================================== -*阅读其它语言版本: [English](intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* +*阅读其它语言版本: [English](../intro.md), [Español](intro_ES.md), [Nederlands](intro_NL.md), [Русский](intro_RU.md), [日本語](intro_JP.md), [Deutsch](intro_DE.md), [Portuguese](intro_PT-BR.md), [Korean](intro_KR.md).* Mimblewimble是一个区块链格式和协议，依托于健壮的加密原语，提供非常好的可扩展性、隐私和可替代性。它解决了当前几乎所有实现的区块链（与现实需求之间）差距。Mimblewimble 的白皮书在[本项目的WiKi](https://github.com/mimblewimble/docs/wiki/A-Brief-History-of-MinbleWimble-White-Paper)中可以找到，WiKi是开放的。 @@ -18,7 +18,7 @@ Grin 项目的主要目的和特性如下: # Tongue Tying for Everyone **备注**：Mimblewimble 出自《哈利波特》中的一句咒语，详见：[Tongue-Tying Curse](http://harrypotter.wikia.com/wiki/Tongue-Tying_Curse)，这个标题的涵义应该是希望所有读到这篇介绍的人都可以来为这个开放社区做点贡献，真心希望如此。 - + 本文针对的读者是已经了解过区块链并了解一些基本的密码学知识的人群。我们尝试解释Mimblewimble的技术构建，以及它如何应用于Grin。我们希望这篇介绍能够浅显易懂，我们的目的是鼓励您对Grin产生兴趣，并加入Grin的开放社区，以任何您可能的方式对其做出贡献。 为了实现这个目标，我们将介绍一个主要概念：Grin是一个Mimblewimble实现。我们将从椭圆曲线密码（ECC）的简短描述开始，这是Grin的重要基础。然后描述Mimblewimble区块链交易和区块的所有关键要素。 @@ -45,7 +45,7 @@ Grin 项目的主要目的和特性如下: Mimblewimble的交易确认依赖于两个基本属性: * **0和验证。** 输出总和减去输入总是等于零，证明交易没有凭空创造新的资金，而且**不会显示实际金额**。 -* **拥有私钥即拥有交易输出的所有权。** 像大多数其他加密货币一样，交易输出通过拥有ECC私钥来保证其所有权。 然而，在Mimblewimble中，证明一个所有者拥有这些私钥并不是通过直接签署交易来实现的。 +* **拥有私钥即拥有交易输出的所有权。** 像大多数其他加密货币一样，交易输出通过拥有ECC私钥来保证其所有权。 然而，在Mimblewimble中，证明一个所有者拥有这些私钥并不是通过直接签署交易来实现的。 下面介绍账户余额、所有权、变更和证明，并借此说明上面的这两个基本属性是如何得以实现的。 @@ -155,7 +155,7 @@ _X_, 上述加法的输出值，是对所有人可见的。 但是值3只有你 例如，可以创建一个输入为2并且输出为5和-3的交易，并且依照前面章节中的定义仍然可以获得平衡的事务。 这是不容易被检测到的，因为即使x是负数，ECDSA曲线上的对应点x.H看起来也是任何值。 -为了解决这个问题，Mimblewimble利用了另一个加密概念（也来自机密交易），称为范围证明：一个数字落在给定范围内的证明，而不会泄露数字。 +为了解决这个问题，Mimblewimble利用了另一个加密概念（也来自机密交易），称为范围证明：一个数字落在给定范围内的证明，而不会泄露数字。 我们不会详细说明范围证明，您只需要知道，对于任何`r.G + v.H`，我们都可以创建一个证明，证明 _v_ 大于零且不会溢出。 同样重要的是要注意，为了从上面的示例中创建有效的范围证明，必须知道在创建和签署excess value时使用的值113和28。 其原因以及范围证明的更详细描述在[range proof paper](https://eprint.iacr.org/2017/1066.pdf)中进一步详述。 @@ -258,7 +258,7 @@ Mimblewimble区块格式通过引入一个附加概念来构建：核销（_cut- * 在这个区块内，一些输出直接被包含的输入消耗（I3花费O2并且I4花费O3）。 * 每笔交易的结构并不重要。 由于所有的单个交易均归于零，因此所有交易输入和输出的总和也必须为零。 -与单个交易类似，所有需要在一个区块中进行检查的是所有权已经被证实（来自交易内核 _transaction kernels_），并且整个区块没有增加任何货币供应（除了coinbase所允许的之外）。 +与单个交易类似，所有需要在一个区块中进行检查的是所有权已经被证实（来自交易内核 _transaction kernels_），并且整个区块没有增加任何货币供应（除了coinbase所允许的之外）。 因此，匹配输入和输出可以被消除，因为它们对总和的贡献被抵消了。 这导致了以下更紧凑的块： I1(x1) | O1 @@ -275,7 +275,7 @@ Mimblewimble区块格式通过引入一个附加概念来构建：核销（_cut- * 每个交易的交易核(transaction kernels)包含： * 从所有commitments总和中获得的公钥`r * G`。 * 使用excess value生成的签名。 - * 挖矿费用 (fee)。 + * 挖矿费用 (fee)。 当区块以这种方式构建时，Mimblewimble区块提供了非常好的隐私保证： @@ -304,5 +304,5 @@ Mimblewimble区块格式通过引入一个附加概念来构建：核销（_cut- ## 结论 -在本文中，我们介绍了基于Mimblewimble区块链的基本原则。 通过使用椭圆曲线密码的附加属性，我们能够构建完全不透明但仍可以正确验证的交易。 +在本文中，我们介绍了基于Mimblewimble区块链的基本原则。 通过使用椭圆曲线密码的附加属性，我们能够构建完全不透明但仍可以正确验证的交易。 通过应用这些属性，我们可以消除大量区块链数据，从而实现新对等点的大规模部署和快速同步。 diff --git a/doc/merkle_KR.md b/doc/translations/merkle_KR.md similarity index 100% rename from doc/merkle_KR.md rename to doc/translations/merkle_KR.md diff --git a/doc/merkle_ZH-CN.md b/doc/translations/merkle_ZH-CN.md similarity index 98% rename from doc/merkle_ZH-CN.md rename to doc/translations/merkle_ZH-CN.md index 697130ae62..b1dee0d083 100644 --- a/doc/merkle_ZH-CN.md +++ b/doc/translations/merkle_ZH-CN.md @@ -1,6 +1,6 @@ # Merkle Structures -*阅读其它语言版本: [English](merkle.md), [Korean](merkle_KR.md).* +*阅读其它语言版本: [English](../merkle.md), [Korean](merkle_KR.md).* Mimblewimble 是设计给用户在仅给出修剪后的数据的情况下也能验证系统状态。 为了实现此目标，所有交易数据都通过 Merkle trees 提交给了区块链，该 Merkle trees 即使在被修剪后也需要在更新和序列化操作上有良好的效率。 diff --git a/doc/translations/mimblewimble.md b/doc/translations/mimblewimble.md new file mode 100644 index 0000000000..dd7df737a6 --- /dev/null +++ b/doc/translations/mimblewimble.md @@ -0,0 +1,263 @@ + https://scalingbitcoin.org/papers/mimblewimble.txt + + MIMBLEWIMBLE + Tom Elvis Jedusor + 19 July, 2016 + + \****/ + Introduction + /****\ + + Bitcoin is the first widely used financial system for which all the necessary + data to validate the system status can be cryptographically verified by anyone. + However, it accomplishes this feat by storing all transactions in a public + database called "the blockchain" and someone who genuinely wishes to check + this state must download the whole thing and basically replay each transaction, + check each one as they go. Meanwhile, most of these transactions have not + affected the actual final state (they create outputs that are destroyed + a transaction later). + + At the time of this writing, there were nearly 150 million transactions + committed in the blockchain, which must be replayed to produce a set of + only 4 million unspent outputs. + + It would be better if an auditor needed only to check data on the outputs + themselves, but this is impossible because they are valid if and only if the + output is at the end of a chain of previous outputs, each signs the next. In + other words, the whole blockchain must be validated to confirm the final + state. + + + Add to this that these transactions are cryptographically atomic, it is clear + what outputs go into every transaction and what emerges. The "transaction graph" + resulting reveals a lot of information and is subjected to analysis by many + companies whose business model is to monitor and control the lower classes. + This makes it very non-private and even dangerous for people to use. + + + Some solutions to this have been proposed. Greg Maxwell discovered to encrypt + the amounts, so that the graph of the transaction is faceless but still allow + validation that the sums are correct [1]. Dr Maxwell also produced CoinJoin, + a system for Bitcoin users to combine interactively transactions, confusing + the transaction graph. Nicolas van Saberhagen has developed a system to blind + the transaction entries, goes much further to cloud the transaction graph (as + well as not needed the user interaction) [3]. Later, Shen Noether combined + the two approaches to obtain "confidential transactions" of Maxwell AND the + darkening of van Saberhagen [4]. + + These solutions are very good and would make Bitcoin very safe to use. But + the problem of too much data is made even worse. Confidential transactions + require multi-kilobyte proofs on every output, and van Saberhagen signatures + require every output to be stored for ever, since it is not possible to tell + when they are truly spent. + + Dr. Maxwell's CoinJoin has the problem of needing interactivity. Dr. Yuan Horas + Mouton fixed this by making transactions freely mergeable [5], but he needed to + use pairing-based cryptography, which is potentially slower and more difficult + to trust. He called this "one-way aggregate signatures" (OWAS). + + OWAS had the good idea to combine the transactions in blocks. Imagine that we + can combine across blocks (perhaps with some glue data) so that when the outputs + are created and destroyed, it is the same as if they never existed. Then, to + validate the entire chain, users only need to know when money is entered into + the system (new money in each block as in Bitcoin or Monero or peg-ins for + sidechains [6]) and final unspent outputs, the rest can be removed and forgotten. + Then we can have Confidential Transactions to hide the amounts and OWAS to blur + the transaction graph, and use LESS space than Bitcoin to allow users to fully + verify the blockchain. And also imagine that we must not pairing-based cryptography + or new hypotheses, just regular discrete logarithms signatures like Bitcoin. + Here is what I propose. + + I call my creation Mimblewimble because it is used to prevent the blockchain from + talking about all user's information [7]. + + + \****/ + Confidential Transactions and OWAS + /****\ + + The first thing we need to do is remove Bitcoin Script. This is sad, but it is too + powerful so it is impossible to merge transactions using general scripts. We will + demonstrate that confidential transactions of Dr. Maxwell are enough (after some + small modification) to authorize spending of outputs and also allows to make + combined transactions without interaction. This is in fact identical to OWAS, + and allows relaying nodes take some transaction fee or the recipient to change + the transaction fees. These additional things Bitcoin can not do, we get for free. + + We start by reminding the reader how confidential transactions work. First, the + amounts are coded by the following equation: + + C = r*G + v*H + + where C is a Pedersen commitment, G and H are fixed nothing-up-my-sleeve elliptic + curve group generators, v is the amount, and r is a secret random blinding key. + + Attached to this output is a rangeproof which proves that v is in [0, 2^64], so + that user cannot exploit the blinding to produce overflow attacks, etc. + + To validate a transaction, the verifer will add commitments for all outputs, plus + f*H (f here is the transaction fee which is given explicitly) and subtracts all + input commitments. The result must be 0, which proves that no amount was created + or destroyed overall. + + We note that to create such a transaction, the user must know the sum of all the + values of r for commitments entries. Therefore, the r-values (and their sums) act + as secret keys. If we can make the r output values known only to the recipient, + then we have an authentication system! Unfortunately, if we keep the rule that + commits all add to 0, this is impossible, because the sender knows the sum of + all _his_ r values, and therefore knows the receipient's r values sum to the + negative of that. So instead, we allow the transaction to sum to a nonzero value + k*G, and require a signature of an empty string with this as key, to prove its + amount component is zero. + + We let transactions have as many k*G values as they want, each with a signature, + and sum them during verification. + + To create transactions sender and recipient do following ritual: + + 1. Sender and recipient agree on amount to be sent. Call this b. + + 2. Sender creates transaction with all inputs and change output(s), and gives + recipient the total blinding factor (r-value of change minus r-values of + inputs) along with this transaction. So the commitments sum to r*G - b*H. + + 3. Recipient chooses random r-values for his outputs, and values that sum + to b minus fee, and adds these to transaction (including range proof). + Now the commitments sum to k*G - fee*H for some k that only recipient + knows. + + 4. Recipient attaches signature with k to the transaction, and the explicit + fee. It has done. + + Now, creating transactions in this manner supports OWAS already. To show this, + suppose we have two transactions that have a surplus k1*G and k2*G, and the + attached signatures with these. Then you can combine the lists of inputs and + outputs of the two transactions, with both k1*G and k2*G to the mix, and + voilá! is again a valid transaction. From the combination, it is impossible to + say which outputs or inputs are from which original transaction. + + Because of this, we change our block format from Bitcoin to this information: + 1. Explicit amounts for new money (block subsidy or sidechain peg-ins) with + whatever else data this needs. For a sidechain peg-in maybe it references + a Bitcoin transaction that commits to a specific excess k*G value? + + 2. Inputs of all transactions + + 3. Outputs of all transactions + + 4. Excess k*G values for all transactions + + Each of these are grouped together because it do not matter what the transaction + boundaries are originally. In addition, Lists 2 3 and 4 should be required to be + coded in alphabetical order, since it is quick to check and prevents the block + creator of leaking any information about the original transactions. + + Note that the outputs are now identified by their hash, and not by their position + in a transaction that could easily change. Therefore, it should be banned to have + two unspent outputs are equal at the same time, to avoid confusion. + + + + \****/ + Merging Transactions Across Blocks + /****\ + + Now, we have used Dr. Maxwell's Confidential Transactions to create a noninteractive + version of Dr. Maxwell's CoinJoin, but we have not seen the last of marvelous Dr. Maxwell! + We need another idea, transaction cut-through, he described in [8]. Again, we create a + noninteractive version of this, and to show how it is used with several blocks. + + We can imagine now each block as one large transaction. To validate it, we add all the + output commitments together, then subtracts all input commitments, k*G values, and all + explicit input amounts times H. We find that we could combine transactions from two + blocks, as we combined transactions to form a single block, and the result is again + a valid transaction. Except now, some output commitments have an input commitment exactly + equal to it, where the first block's output was spent in the second block. We could + remove both commitments and still have a valid transaction. In fact, there is not even + need to check the rangeproof of the deleted output. + + The extension of this idea all the way from the genesis block to the latest block, we + see that EVERY nonexplicit input is deleted along with its referenced output. What + remains are only the unspent outputs, explicit input amounts and every k*G value. + And this whole mess can be validated as if it were one transaction: add all unspent + commitments output, subtract the values k*G, validate explicit input amounts (if there + is anything to validate) then subtract them times H. If the sum is 0, the entire + chain is good. + + What is this mean? When a user starts up and downloads the chain he needs the following + data from each block: + + 1. Explicit amounts for new money (block subsidy or sidechain peg-ins) with + whatever else data this needs. + + 2. Unspent outputs of all transactions, along with a merkle proof that each + output appeared in the original block. + + 3. Excess k*G values for all transactions. + + Bitcoin today there are about 423000 blocks, totaling 80GB or so of data on the hard + drive to validate everything. These data are about 150 million transactions and 5 million + unspent nonconfidential outputs. Estimate how much space the number of transactions + take on a Mimblewimble chain. Each unspent output is around 3Kb for rangeproof and + Merkle proof. Each transaction also adds about 100 bytes: a k*G value and a signature. + The block headers and explicit amounts are negligible. Add this together and get + 30Gb -- with a confidential transaction and obscured transaction graph! + + + \****/ + Questions and Intuition + /****\ + + Here are some questions that since these weeks, dreams asked me and I woke up sweating. + But in fact it is OK. + + Q. If you delete the transaction outputs, user cannot verify the rangeproof and maybe + a negative amount is created. + + A. This is OK. For the entire transaction to validate all negative amounts must have + been destroyed. User have SPV security only that no illegal inflation happened in + the past, but the user knows that _at this time_ no inflation occurred. + + + Q. If you delete the inputs, double spending can happen. + + A. In fact, this means: maybe someone claims that some unspent output was spent + in the old days. But this is impossible, otherwise the sum of the combined transaction + could not be zero. + + An exception is that if the outputs are amount zero, it is possible to make two that + are negatives of each other, and the pair can be revived without anything breaks. So to + prevent consensus problems, outputs 0-amount should be banned. Just add H at each output, + now they all amount to at least 1. + + + + \****/ + Future Research + /****\ + + Here are some questions I can not answer at the time of this writing. + + 1. What script support is possible? We would need to translate script operations into + some sort of discrete logarithm information. + + 2. We require user to check all k*G values, when in fact all that is needed is that their + sum is of the form k*G. Instead of using signatures is there another proof of discrete + logarithm that could be combined? + + 3. There is a denial-of-service option when a user downloads the chain, the peer can give + gigabytes of data and list the wrong unspent outputs. The user will see that the result + do not add up to 0, but cannot tell where the problem is. + + For now maybe the user should just download the blockchain from a Torrent or something + where the data is shared between many users and is reasonably likely to be correct. + + + [1] https://people.xiph.org/~greg/confidential_values.txt + [2] https://bitcointalk.org/index.php?topic=279249.0 + [3] https://cryptonote.org/whitepaper.pdf + [4] https://eprint.iacr.org/2015/1098.pdf + [5] https://download.wpsoftware.net/bitcoin/wizardry/horasyuanmouton-owas.pdf + [6] http://blockstream.com/sidechains.pdf + [7] http://fr.harrypotter.wikia.com/wiki/Sortilège_de_Langue_de_Plomb + [8] https://bitcointalk.org/index.php?topic=281848.0 diff --git a/doc/mmr_KR.md b/doc/translations/mmr_KR.md similarity index 97% rename from doc/mmr_KR.md rename to doc/translations/mmr_KR.md index 9b97816da5..6b693e1e5b 100644 --- a/doc/mmr_KR.md +++ b/doc/translations/mmr_KR.md @@ -1,12 +1,12 @@ # Merkle Mountain Ranges -*다른 언어로 되어있는 문서를 읽으려면: [English](mmr.md), [简体中文](mmr_ZH-CN.md).* +*다른 언어로 되어있는 문서를 읽으려면: [English](../mmr.md), [简体中文](mmr_ZH-CN.md).* ## MMR의 구조 Merkle Mountain Ranges [1]은 Merkle trees [2]의 대안입니다. 후자는 완벽하게 균형 잡힌 이진 트리를 사용하지만 전자는 완벽하게 균형잡힌 binary tree list 거나 오른쪽 상단에서 잘린 single binary tree로 볼 수 있습니다. Merkle Mountain Range (MMR)는 엄격하게 append 에서만 사용됩니다. 원소는 왼쪽에서 오른쪽으로 추가되고, 두 하위 원소가 있는 즉시 부모를 추가하여 그에 따라 범위를 채웁니다. -다음 그림은 각 노드를 삽입 순서대로 표시한 것입니다. 11 개의 삽입 된 리프와 총크기 19가 있는 range 를 표시합니다. +다음 그림은 각 노드를 삽입 순서대로 표시한 것입니다. 11 개의 삽입 된 리프와 총크기 19가 있는 range 를 표시합니다. ``` Height @@ -23,7 +23,7 @@ Height 0 0 1 3 4 7 8 10 11 15 16 18 ``` -이 구조는 편평한 리스트로 표시할 수 있습니다. 여기서는 각 노드의 삽입 포지션에서 노드의 높이를 나타냅니다. ( 위의 그림과 아래의 평면 리스트를 비교하면 이해가 쉬움 - 역자 주 ) +이 구조는 편평한 리스트로 표시할 수 있습니다. 여기서는 각 노드의 삽입 포지션에서 노드의 높이를 나타냅니다. ( 위의 그림과 아래의 평면 리스트를 비교하면 이해가 쉬움 - 역자 주 ) ``` 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 @@ -110,7 +110,7 @@ Height 2 6 13 / / \ 1 2 9 12 17 - \ / / \ / + \ / / \ / 0 1 7 10 11 15 18 ``` diff --git a/doc/mmr_ZH-CN.md b/doc/translations/mmr_ZH-CN.md similarity index 98% rename from doc/mmr_ZH-CN.md rename to doc/translations/mmr_ZH-CN.md index 161b0174a7..9ebaa89daf 100644 --- a/doc/mmr_ZH-CN.md +++ b/doc/translations/mmr_ZH-CN.md @@ -1,6 +1,6 @@ # Merkle Mountain Ranges -*阅读其它语言版本: [English](mmr.md), [Korean](mmr_KR.md).* +*阅读其它语言版本: [English](../mmr.md), [Korean](mmr_KR.md).* ## 结构 @@ -124,7 +124,7 @@ P = Blake2b(N | Blake2b(N | Node(p3) | Node(p2)) | Node(p1)) 2 6 13 / / \ 1 2 9 12 17 - \ / / \ / + \ / / \ / 0 1 7 10 11 15 18 ``` diff --git a/doc/pruning_KR.md b/doc/translations/pruning_KR.md similarity index 100% rename from doc/pruning_KR.md rename to doc/translations/pruning_KR.md diff --git a/doc/pruning_ZH-CN.md b/doc/translations/pruning_ZH-CN.md similarity index 97% rename from doc/pruning_ZH-CN.md rename to doc/translations/pruning_ZH-CN.md index 79715d7921..1afad4ac2c 100644 --- a/doc/pruning_ZH-CN.md +++ b/doc/translations/pruning_ZH-CN.md @@ -1,6 +1,6 @@ # 修剪区块链数据 -*阅读其它语言版本: [English](pruning.md), [Korean](pruning_KR.md).* +*阅读其它语言版本: [English](../pruning.md), [Korean](pruning_KR.md).* Mimblewimble 的主要吸引力之一是其理论空间效率。确实，一个受信任或预先验证的完整区块链状态仅需要未花费的交易输出，它可以非常小。 @@ -57,5 +57,5 @@ grin 的区块链包括以下类型的数据（我们假设对 Mimblewimble 协 * 所有内核，按包含在链中的顺序。这也允许重建内核 MMR。 * 所有未花费的输出。 * UTXO MMR 和 范围证明 MMR（以了解修剪后的数据的哈希值）。 - + 请注意，可以通过仅验证一个由验证节点随机选择的范围证明的子集来进行进一步修剪。 diff --git a/doc/state_JP.md b/doc/translations/state_JP.md similarity index 97% rename from doc/state_JP.md rename to doc/translations/state_JP.md index 1d38467689..59046547fb 100644 --- a/doc/state_JP.md +++ b/doc/translations/state_JP.md @@ -1,6 +1,6 @@ # 状態とストレージ -*別の言語で読む: [English](state.md), [Korean](state_KR.md), [简体中文](state_ZH-CN.md).* +*別の言語で読む: [English](../state.md), [Korean](state_KR.md), [简体中文](state_ZH-CN.md).* ## Grinの状態 diff --git a/doc/state_KR.md b/doc/translations/state_KR.md similarity index 97% rename from doc/state_KR.md rename to doc/translations/state_KR.md index 459816d940..0b0d4a7eb9 100644 --- a/doc/state_KR.md +++ b/doc/translations/state_KR.md @@ -1,6 +1,6 @@ # 상태와 스토리지 -*다른 언어로 되어있는 문서를 읽으려면: [English](state.md), [日本語](state_JP.md), [简体中文](state_ZH-CN.md).* +*다른 언어로 되어있는 문서를 읽으려면: [English](../state.md), [日本語](state_JP.md), [简体中文](state_ZH-CN.md).* ## Grin의 상태 @@ -12,7 +12,7 @@ Grin chain의 모든 상태는 다음 데이터와 같이 이루어져 있습니 1. 각 출력값에 대한 range proof 1. 모든 트랜잭션 커널(kernel)들 1. 1,2,3번의 각각의 MMR들 (예외적으로 출력값 MMR은 사용되지 않은 것 뿐만 아니라 *모든* 출력값의 해쉬를 포함합니다.) - + 더해서, 유효한 Proof of work 와 함께 chain 안의 모든 헤더들은 상기 상태에 대해 고정되어야 합니다. (상태는 가장 많이 일한 체인과 일치합니다.) 한번 각각의 range proof 가 인증되고 모든 kernel의 실행 합계가 계산되었다면 range proof와 kernel 들은 node 의 작동에 꼭 필요하진 않습니다. diff --git a/doc/state_ZH-CN.md b/doc/translations/state_ZH-CN.md similarity index 96% rename from doc/state_ZH-CN.md rename to doc/translations/state_ZH-CN.md index 54f3e97656..5965bdc9b5 100644 --- a/doc/state_ZH-CN.md +++ b/doc/translations/state_ZH-CN.md @@ -1,6 +1,6 @@ # 状态和存储 -*阅读其它语言版本: [English](state.md), [Korean](state_KR.md), [日本語](state_JP.md).* +*阅读其它语言版本: [English](../state.md), [Korean](state_KR.md), [日本語](state_JP.md).* ## Grin 的状态 diff --git a/doc/stratum_KR.md b/doc/translations/stratum_KR.md similarity index 100% rename from doc/stratum_KR.md rename to doc/translations/stratum_KR.md diff --git a/doc/stratum_ZH-CN.md b/doc/translations/stratum_ZH-CN.md similarity index 97% rename from doc/stratum_ZH-CN.md rename to doc/translations/stratum_ZH-CN.md index 37a79fa849..38b9418136 100644 --- a/doc/stratum_ZH-CN.md +++ b/doc/translations/stratum_ZH-CN.md @@ -1,6 +1,6 @@ # Grin Stratum RPC 协议 -*阅读其它语言版本: [Korean](stratum_KR.md)，[English](stratum.md).* +*阅读其它语言版本: [Korean](../stratum_KR.md)，[English](stratum.md).* 本文说明在 Grin 部署目前的 Stratum RPC 协议。 @@ -33,11 +33,11 @@ 范例： ```JSON -{ +{ "id":"10", "jsonrpc":"2.0", "method":"getjobtemplate", - "error":{ + "error":{ "code":-32500, "message":"login first" } @@ -56,11 +56,11 @@ 范例： ```JSON -{ +{ "id":"10", "jsonrpc":"2.0", "method":"getgrins", - "error":{ + "error":{ "code":-32601, "message":"Method not found" } @@ -84,7 +84,7 @@ 范例： ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"getjobtemplate", @@ -101,11 +101,11 @@ 范例： ``` JSON -{ +{ "id":"0", "jsonrpc":"2.0", "method":"getjobtemplate", - "result":{ + "result":{ "difficulty":1, "height":13726, "job_id":4, @@ -128,11 +128,11 @@ 范例： ```JSON -{ +{ "id":"10", "jsonrpc":"2.0", "method":"getjobtemplate", - "error":{ + "error":{ "code":-32000, "message":"Node is syncing - Please wait" } @@ -155,11 +155,11 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 范例： ``` JSON -{ +{ "id":"Stratum", "jsonrpc":"2.0", "method":"job", - "params":{ + "params":{ "difficulty":1, "height":16375, "job_id":5, @@ -188,7 +188,7 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 范例： ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"keepalive", @@ -209,7 +209,7 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 范例： ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"keepalive", @@ -237,11 +237,11 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 ``` JSON -{ +{ "id":"0", "jsonrpc":"2.0", "method":"login", - "params":{ + "params":{ "login":"login", "pass":"password", "agent":"grin-miner" @@ -266,7 +266,7 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 范例： ``` JSON -{ +{ "id":"1", "jsonrpc":"2.0", "method":"login", @@ -295,7 +295,7 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 范例： ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"status", @@ -318,11 +318,11 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 范例： ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"status", - "result":{ + "result":{ "id":"5", "height":13726, "difficulty":1, @@ -361,7 +361,7 @@ Stratum 服务器发起新消息。Stratum 服务器会自动发送工作给连 "height":16419, "job_id":0, "nonce":8895699060858340771, - "pow":[ + "pow":[ 4210040,10141596,13269632,24291934,28079062,84254573,84493890,100560174,100657333,120128285,130518226,140371663,142109188,159800646,163323737,171019100,176840047,191220010,192245584,198941444,209276164,216952635,217795152,225662613,230166736,231315079,248639876,263910393,293995691,298361937,326412694,330363619,414572127,424798984,426489226,466671748,466924466,490048497,495035248,496623057,502828197, 532838434 ] } @@ -387,7 +387,7 @@ Stratum 接受份额，但不是目前网络目标难度的有效 cuck(at)oo 解 范例： ``` JSON -{ +{ "id":"2", "jsonrpc":"2.0", "method":"submit", @@ -411,7 +411,7 @@ Stratum 接受份额，但不是目前网络目标难度的有效 cuck(at)oo 解 范例： ``` JSON -{ +{ "id":"6", "jsonrpc":"2.0", "method":"submit", @@ -438,11 +438,11 @@ Stratum 接受份额，但不是目前网络目标难度的有效 cuck(at)oo 解 范例： ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"submit", - "error":{ + "error":{ "code":-32503, "message":"Solution submitted too late" } @@ -467,11 +467,11 @@ Stratum 接受份额，但不是目前网络目标难度的有效 cuck(at)oo 解 范例： ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"submit", - "error":{ + "error":{ "code":-32502, "message":"Failed to validate solution" } @@ -492,11 +492,11 @@ Stratum 接受份额，但不是目前网络目标难度的有效 cuck(at)oo 解 范例： ```JSON -{ +{ "id":"5", "jsonrpc":"2.0", "method":"submit", - "error":{ + "error":{ "code":-32501, "message":"Share rejected due to low difficulty" } diff --git a/doc/switch_commitment_ZH-CN.md b/doc/translations/switch_commitment_ZH-CN.md similarity index 98% rename from doc/switch_commitment_ZH-CN.md rename to doc/translations/switch_commitment_ZH-CN.md index 2b847cada5..f4122d1f19 100644 --- a/doc/switch_commitment_ZH-CN.md +++ b/doc/translations/switch_commitment_ZH-CN.md @@ -1,6 +1,6 @@ # 秘诺切换简介 -*阅读其它语言版本： [English](switch_commitment.md)* +*阅读其它语言版本： [English](../switch_commitment.md)* ## 概述 @@ -31,7 +31,7 @@ 这个“盒子”的比喻在现实世界中看似不合理，但对椭圆曲线原理无可挑剔。 -如需了解关于 Pedersen Commitment 的详情，请参阅[《Mimblewimble 和 Grin 简介》](intro_ZH-CN.md) +如需了解关于 Pedersen Commitment 的详情，请参阅[《Mimblewimble 和 Grin 简介》](intro_ZH-CN.md) ## 秘诺方案特性： @@ -39,7 +39,7 @@ 一般而言，秘诺有两大特性，强弱变化视秘诺方案类型而变。 - **隐匿性（或机密性）：**秘诺方案保护秘诺的强度。或依上述范例：攻击者没有钥匙怎么能打开盒子（知道密数）？ - + - **绑定性：**攻击者是否可以找到匹配同一秘诺的不同密数，攻击者之后通过秘诺打开的就是不同秘诺。这样秘诺的_致盲性_就被破解。 ### 两种特性的安全性： @@ -156,9 +156,9 @@ Pedersen Commitments 已经是_完美绑定_。所以无论发生什么，无需 但这种情况下用户仍有选择： - 用户可决定继续创建新交易。即使因为 ElGamal 秘诺方案仅为计算隐匿，有可能破坏隐私性（只对**上一个** UTXO），但用户至少仍旧可以存取自己的币。 - + - 或者用户可决定不管钱，不做任何交易（但是保留隐私性，因为他们的交易仅验证有完美隐匿性的 Pedersen 秘诺） 有些情况下，隐私泄露对某个人的生命安全威胁要高过一定加密货币的损失。但决策权应该留给个人用户，秘诺切换就实现了这种选择。 -需要明确的是，这一安全措施只有在遇到意外灾难的情况下才会启用。若计算有所进步，离散对数难题受到质疑，那包括加密货币在内的众多其他加密系统都需要紧急更新原语，抵抗未来潜在威胁。秘诺切换只是在 Pedersen Commitments 被意外破解情况下，提供额外的安全保护方案。 \ No newline at end of file +需要明确的是，这一安全措施只有在遇到意外灾难的情况下才会启用。若计算有所进步，离散对数难题受到质疑，那包括加密货币在内的众多其他加密系统都需要紧急更新原语，抵抗未来潜在威胁。秘诺切换只是在 Pedersen Commitments 被意外破解情况下，提供额外的安全保护方案。 diff --git a/doc/table_of_contents_KR.md b/doc/translations/table_of_contents_KR.md similarity index 100% rename from doc/table_of_contents_KR.md rename to doc/translations/table_of_contents_KR.md diff --git a/doc/table_of_contents_ZH-CN.md b/doc/translations/table_of_contents_ZH-CN.md similarity index 94% rename from doc/table_of_contents_ZH-CN.md rename to doc/translations/table_of_contents_ZH-CN.md index 115016122e..85de49cd3a 100644 --- a/doc/table_of_contents_ZH-CN.md +++ b/doc/translations/table_of_contents_ZH-CN.md @@ -1,6 +1,6 @@ # 文档结构 -*阅读其它语言版本： [English](table_of_contents.md)，[Korean](table_of_contents_KR.md)* +*阅读其它语言版本： [English](../table_of_contents.md)，[Korean](table_of_contents_KR.md)* ## Grin 详解 diff --git a/doc/validation/validation_logic.md b/doc/validation/validation_logic.md new file mode 100644 index 0000000000..900c94acbc --- /dev/null +++ b/doc/validation/validation_logic.md @@ -0,0 +1,48 @@ +# Standalone Validations Logic + +## Transaction + +* Validate the "transaction body" + * Validate the total weight, including reward is lower than the consensus max weight + * Validate the sorting of inputs, outputs and kernels by their hashes + * Validate the outputs have all been fully cut-through (no inputs matching an included output) + * Batch verify all output range proofs (but only those that aren't in the validation cache yet) + * Verify all kernel signatures against the excess and the message (fee+lock_time?) +* Verify no output or kernel include invalid features (coinbase) +* Verify the big "sum": all inputs plus reward+fee, all output commitments, all kernels plus the kernel excess + +## Block + +* Validate the "transaction body" as with transactions +* Verify no kernels have a future lock height +* Check that the reward plus fees "sums" correctly with the coinbase outputs commitments and kernels excess +* Verify the big "sum": all inputs plus reward+fee, all output commitments, all kernels plus the kernel excess from the header + +# Chain validations + +Headers and blocks have a quick rejection check first when they've already gone through validation and have either been accepted or definitely rejected (non orphans, no local error). + +## Header + +In all header difficulty calculations, the difficulty proven by the proof-of-work is subject to adjustments due to either Cuckatoo sizes or Cuckaroo scaling factor. + +* Check the version against what we're expecting at the moment given a hard fork schedule. +* Check the header timestamp isn't too far off in the future (12 * block time) +* Check we either have a primary or secondary proof of work solution +* Check the solution is a valid Cuck(ar|at)oo cycle of the required length (42) +* Check the previous block header exists +* Check the heights are coherent (previous + 1) +* Check the header timestamp is strictly greater than the previous +* Check the header PoW total difficulty is greater than the previous one +* Check the header PoW satisfies the network difficulty claimed in the header +* Check the calculated network difficulty equals the header claimed network difficulty +* Check the header secondary scaling factor matches the network calculated one +* Validate the previous header MMR root is correct against the local MMR. + +## Block + +* Run full header validation +* Check we have the previous full block (orphan otherwise) +* Run standalone block validation +* Validate the MMRs roots and sizes against our header +* Block header goes through full header validation