Remove \r
This commit is contained in:
parent
67d7375ab9
commit
d6d5b4429c
|
@ -1,64 +1,64 @@
|
|||
## Problem
|
||||
|
||||
Inter-chain applications are not new to the digital asset ecosystem; in fact, even
|
||||
the smaller centralized exchanges still categorically dwarf all single chain dapps
|
||||
put together in terms of users and volume. They command massive valuations and
|
||||
have spent years effectively optimizing their core products for a broad range of
|
||||
end users. However, their basic operations center around mechanisms that require
|
||||
their users to unilaterally trust them, typically with little to no recourse
|
||||
or protection from accidental loss. This has led to the broader digital asset
|
||||
ecosystem being fractured along network lines because interoperability solutions typically:
|
||||
* Are technically complex to fully implement
|
||||
* Create unstable network scale incentive structures
|
||||
* Require consistent and high level cooperation between stakeholders
|
||||
|
||||
|
||||
## Proposed Solution
|
||||
|
||||
Simple Payment Verification (SPV) is a generic term for a range of different
|
||||
methodologies used by light clients on most major blockchain networks to verify
|
||||
aspects of the network state without the burden of fully storing and maintaining
|
||||
the chain itself. In most cases, this means relying on a form of hash tree to
|
||||
supply a proof of the presence of a given transaction in a certain block by
|
||||
comparing against a root hash in that block’s header or equivalent. This allows
|
||||
a light client or wallet to reach a probabilistic level of certainty about
|
||||
on-chain events by itself with a minimum of trust required with regard to network nodes.
|
||||
|
||||
Traditionally the process of assembling and validating these proofs is carried
|
||||
out off chain by nodes, wallets, or other clients, but it also offers a potential
|
||||
mechanism for inter-chain state verification. However, by moving the capability
|
||||
to validate SPV proofs on-chain as a smart contract while leveraging the archival
|
||||
properties inherent to the blockchain, it is possible to construct a system for
|
||||
programmatically detecting and verifying transactions on other networks without
|
||||
the involvement of any type of trusted oracle or complex multi-stage consensus
|
||||
mechanism. This concept is broadly generalisable to any network with an SPV
|
||||
mechanism and can even be operated bilaterally on other smart contract platforms,
|
||||
opening up the possibility of cheap, fast, inter-chain transfer of value without
|
||||
relying on collateral, hashlocks, or trusted intermediaries.
|
||||
|
||||
Opting to take advantage of well established and developmentally stable mechanisms
|
||||
already common to all major blockchains allows SPV based interoperability solutions
|
||||
to be dramatically simpler than orchestrated multi-stage approaches. As part of
|
||||
this, they dispense with the need for widely agreed upon cross chain communication
|
||||
standards and the large multi-party organizations that write them in favor of a
|
||||
set of discrete contract-based services that can be easily utilized by caller
|
||||
contracts through a common abstraction format. This will set the groundwork for
|
||||
a broad range of dapps and contracts able to interoperate across the variegated
|
||||
and every growing platform ecosystem.
|
||||
|
||||
## Terminology
|
||||
|
||||
SPV Program - Client-facing interface for the inter-chain SPV system, manages participant roles.
|
||||
SPV Engine - Validates transaction proofs, subset of the SPV Program.
|
||||
Client - The caller to the SPV Program, typically another solana contract.
|
||||
Prover - Party who generates proofs for transactions and submits them to the SPV Program.
|
||||
Transaction Proof - Created by Provers, contains a merkle proof, transaction, and blockheader reference.
|
||||
Merkle Proof - Basic SPV proof that validates the presence of a transaction in a certain block.
|
||||
Block Header - Represents the basic parameters and relative position of a given block.
|
||||
Proof Request - An order placed by a client for verification of transaction(s) by provers.
|
||||
Header Store - A data structure for storing and referencing ranges of block headers in proofs.
|
||||
Client Request - Transaction from the client to the SPV Program to trigger creation of a Proof Request.
|
||||
Sub-account - A Solana account owned by another contract account, without its own private key.
|
||||
|
||||
For more information on the Inter-chain SPV system, see the book section at:
|
||||
https://solana-labs.github.io/book/interchain-transaction-verification.html
|
||||
## Problem
|
||||
|
||||
Inter-chain applications are not new to the digital asset ecosystem; in fact, even
|
||||
the smaller centralized exchanges still categorically dwarf all single chain dapps
|
||||
put together in terms of users and volume. They command massive valuations and
|
||||
have spent years effectively optimizing their core products for a broad range of
|
||||
end users. However, their basic operations center around mechanisms that require
|
||||
their users to unilaterally trust them, typically with little to no recourse
|
||||
or protection from accidental loss. This has led to the broader digital asset
|
||||
ecosystem being fractured along network lines because interoperability solutions typically:
|
||||
* Are technically complex to fully implement
|
||||
* Create unstable network scale incentive structures
|
||||
* Require consistent and high level cooperation between stakeholders
|
||||
|
||||
|
||||
## Proposed Solution
|
||||
|
||||
Simple Payment Verification (SPV) is a generic term for a range of different
|
||||
methodologies used by light clients on most major blockchain networks to verify
|
||||
aspects of the network state without the burden of fully storing and maintaining
|
||||
the chain itself. In most cases, this means relying on a form of hash tree to
|
||||
supply a proof of the presence of a given transaction in a certain block by
|
||||
comparing against a root hash in that block’s header or equivalent. This allows
|
||||
a light client or wallet to reach a probabilistic level of certainty about
|
||||
on-chain events by itself with a minimum of trust required with regard to network nodes.
|
||||
|
||||
Traditionally the process of assembling and validating these proofs is carried
|
||||
out off chain by nodes, wallets, or other clients, but it also offers a potential
|
||||
mechanism for inter-chain state verification. However, by moving the capability
|
||||
to validate SPV proofs on-chain as a smart contract while leveraging the archival
|
||||
properties inherent to the blockchain, it is possible to construct a system for
|
||||
programmatically detecting and verifying transactions on other networks without
|
||||
the involvement of any type of trusted oracle or complex multi-stage consensus
|
||||
mechanism. This concept is broadly generalisable to any network with an SPV
|
||||
mechanism and can even be operated bilaterally on other smart contract platforms,
|
||||
opening up the possibility of cheap, fast, inter-chain transfer of value without
|
||||
relying on collateral, hashlocks, or trusted intermediaries.
|
||||
|
||||
Opting to take advantage of well established and developmentally stable mechanisms
|
||||
already common to all major blockchains allows SPV based interoperability solutions
|
||||
to be dramatically simpler than orchestrated multi-stage approaches. As part of
|
||||
this, they dispense with the need for widely agreed upon cross chain communication
|
||||
standards and the large multi-party organizations that write them in favor of a
|
||||
set of discrete contract-based services that can be easily utilized by caller
|
||||
contracts through a common abstraction format. This will set the groundwork for
|
||||
a broad range of dapps and contracts able to interoperate across the variegated
|
||||
and every growing platform ecosystem.
|
||||
|
||||
## Terminology
|
||||
|
||||
SPV Program - Client-facing interface for the inter-chain SPV system, manages participant roles.
|
||||
SPV Engine - Validates transaction proofs, subset of the SPV Program.
|
||||
Client - The caller to the SPV Program, typically another solana contract.
|
||||
Prover - Party who generates proofs for transactions and submits them to the SPV Program.
|
||||
Transaction Proof - Created by Provers, contains a merkle proof, transaction, and blockheader reference.
|
||||
Merkle Proof - Basic SPV proof that validates the presence of a transaction in a certain block.
|
||||
Block Header - Represents the basic parameters and relative position of a given block.
|
||||
Proof Request - An order placed by a client for verification of transaction(s) by provers.
|
||||
Header Store - A data structure for storing and referencing ranges of block headers in proofs.
|
||||
Client Request - Transaction from the client to the SPV Program to trigger creation of a Proof Request.
|
||||
Sub-account - A Solana account owned by another contract account, without its own private key.
|
||||
|
||||
For more information on the Inter-chain SPV system, see the book section at:
|
||||
https://solana-labs.github.io/book/interchain-transaction-verification.html
|
||||
|
|
Loading…
Reference in New Issue