gaspersic/solana
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Remove \r

Browse Source
This commit is contained in:
Michael Vines
2019-09-20 16:04:50 -07:00
parent 67d7375ab9
commit d6d5b4429c
1 changed files with 64 additions and 64 deletions
Download Patch File Download Diff File Expand all files Collapse all files

128
programs/btc_spv_api/README.md
View File

@ -1,64 +1,64 @@
## Problem ## Problem
Inter-chain applications are not new to the digital asset ecosystem; in fact, even 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 the smaller centralized exchanges still categorically dwarf all single chain dapps
put together in terms of users and volume. They command massive valuations and 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 have spent years effectively optimizing their core products for a broad range of
end users. However, their basic operations center around mechanisms that require end users. However, their basic operations center around mechanisms that require
their users to unilaterally trust them, typically with little to no recourse 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 or protection from accidental loss. This has led to the broader digital asset
ecosystem being fractured along network lines because interoperability solutions typically: ecosystem being fractured along network lines because interoperability solutions typically:
* Are technically complex to fully implement * Are technically complex to fully implement
* Create unstable network scale incentive structures * Create unstable network scale incentive structures
* Require consistent and high level cooperation between stakeholders * Require consistent and high level cooperation between stakeholders
## Proposed Solution ## Proposed Solution
Simple Payment Verification (SPV) is a generic term for a range of different 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 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 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 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 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 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 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. 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 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 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 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 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 properties inherent to the blockchain, it is possible to construct a system for
programmatically detecting and verifying transactions on other networks without programmatically detecting and verifying transactions on other networks without
the involvement of any type of trusted oracle or complex multi-stage consensus 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. This concept is broadly generalisable to any network with an SPV
mechanism and can even be operated bilaterally on other smart contract platforms, 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 opening up the possibility of cheap, fast, inter-chain transfer of value without
relying on collateral, hashlocks, or trusted intermediaries. relying on collateral, hashlocks, or trusted intermediaries.
Opting to take advantage of well established and developmentally stable mechanisms Opting to take advantage of well established and developmentally stable mechanisms
already common to all major blockchains allows SPV based interoperability solutions already common to all major blockchains allows SPV based interoperability solutions
to be dramatically simpler than orchestrated multi-stage approaches. As part of 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 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 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 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 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 a broad range of dapps and contracts able to interoperate across the variegated
and every growing platform ecosystem. and every growing platform ecosystem.
## Terminology ## Terminology
SPV Program - Client-facing interface for the inter-chain SPV system, manages participant roles. SPV Program - Client-facing interface for the inter-chain SPV system, manages participant roles.
SPV Engine - Validates transaction proofs, subset of the SPV Program. SPV Engine - Validates transaction proofs, subset of the SPV Program.
Client - The caller to the SPV Program, typically another solana contract. 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. 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. 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. 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. 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. 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. 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. 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. 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: For more information on the Inter-chain SPV system, see the book section at:
https://solana-labs.github.io/book/interchain-transaction-verification.html https://solana-labs.github.io/book/interchain-transaction-verification.html