-
Notifications
You must be signed in to change notification settings - Fork 6
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
9 changed files
with
188 additions
and
8 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,54 @@ | ||
public final class TSDKProofsModule { | ||
|
||
private var binding: TSDKBindingModule | ||
public let module: String = "proofs" | ||
|
||
public init(binding: TSDKBindingModule) { | ||
self.binding = binding | ||
} | ||
|
||
/// Proves that a given block's data, which is queried from TONOS API, can be trusted. | ||
/// This function checks block proofs and compares given data with the proven. | ||
/// If the given data differs from the proven, the exception will be thrown. | ||
/// The input param is a single block's JSON object, which was queried from DApp server usingfunctions such as `net.query`, `net.query_collection` or `net.wait_for_collection`. | ||
/// If block's BOC is not provided in the JSON, it will be queried from DApp server(in this case it is required to provide at least `id` of block). | ||
/// Please note, that joins (like `signatures` in `Block`) are separated entities and not supported,so function will throw an exception in a case if JSON being checked has such entities in it. | ||
/// If `cache_in_local_storage` in config is set to `true` (default), downloaded proofs andmaster-chain BOCs are saved into the persistent local storage (e.g. file system for nativeenvironments or browser's IndexedDB for the web); otherwise all the data is cached only inmemory in current client's context and will be lost after destruction of the client. | ||
/// **Why Proofs are needed**Proofs are needed to ensure that the data downloaded from a DApp server is real blockchaindata. Checking proofs can protect from the malicious DApp server which can potentially providefake data, or also from "Man in the Middle" attacks class. | ||
/// **What Proofs are**Simply, proof is a list of signatures of validators', which have signed this particular master-block. | ||
/// The very first validator set's public keys are included in the zero-state. Whe know a root hashof the zero-state, because it is stored in the network configuration file, it is our authorityroot. For proving zero-state it is enough to calculate and compare its root hash. | ||
/// In each new validator cycle the validator set is changed. The new one is stored in a key-block,which is signed by the validator set, which we already trust, the next validator set will bestored to the new key-block and signed by the current validator set, and so on. | ||
/// In order to prove any block in the master-chain we need to check, that it has been signed bya trusted validator set. So we need to check all key-blocks' proofs, started from the zero-stateand until the block, which we want to prove. But it can take a lot of time and traffic todownload and prove all key-blocks on a client. For solving this, special trusted blocks are usedin TON-SDK. | ||
/// The trusted block is the authority root, as well, as the zero-state. Each trusted block is the`id` (e.g. `root_hash`) of the already proven key-block. There can be plenty of trustedblocks, so there can be a lot of authority roots. The hashes of trusted blocks for MainNetand DevNet are hardcoded in SDK in a separated binary file (trusted_key_blocks.bin) and canbe updated for each release. | ||
/// In future SDK releases, one will also be able to provide their hashes of trusted blocks forother networks, besides for MainNet and DevNet. | ||
/// By using trusted key-blocks, in order to prove any block, we can prove chain of key-blocks tothe closest previous trusted key-block, not only to the zero-state. | ||
/// But shard-blocks don't have proofs on DApp server. In this case, in order to prove any shard-block data, we search for a corresponding master-block, which contains the root hash of thisshard-block, or some shard block which is linked to that block in shard-chain. After provingthis master-block, we traverse through each link and calculate and compare hashes with links,one-by-one. After that we can ensure that this shard-block has also been proven. | ||
public func proof_block_data(_ payload: TSDKParamsOfProofBlockData, _ handler: @escaping (TSDKBindingResponse<TSDKNoneResult, TSDKClientError>) throws -> Void | ||
) { | ||
let method: String = "proof_block_data" | ||
binding.requestLibraryAsync(methodName(module, method), payload) { (requestId, params, responseType, finished) in | ||
var response: TSDKBindingResponse<TSDKNoneResult, TSDKClientError> = .init() | ||
response.update(requestId, params, responseType, finished) | ||
try handler(response) | ||
} | ||
} | ||
|
||
/// Proves that a given transaction's data, which is queried from TONOS API, can be trusted. | ||
/// This function requests the corresponding block, checks block proofs, ensures that given transactionexists in the proven block and compares given data with the proven. | ||
/// If the given data differs from the proven, the exception will be thrown. | ||
/// The input parameter is a single transaction's JSON object (see params description),which was queried from TONOS API using functions such as `net.query`, `net.query_collection`or `net.wait_for_collection`. | ||
/// If transaction's BOC and/or `block_id` are not provided in the JSON, they will be queried fromTONOS API (in this case it is required to provide at least `id` of transaction). | ||
/// Please note, that joins (like `account`, `in_message`, `out_messages`, etc. in `Transaction`entity) are separated entities and not supported, so function will throw an exception in a caseif JSON being checked has such entities in it. | ||
/// If `cache_in_local_storage` in config is set to `true` (default), downloaded proofs andmaster-chain BOCs are saved into the persistent local storage (e.g. file system for nativeenvironments or browser's IndexedDB for the web); otherwise all the data is cached only inmemory in current client's context and will be lost after destruction of the client. | ||
/// For more information about proofs checking, see description of `proof_block_data` function. | ||
public func proof_transaction_data(_ payload: TSDKParamsOfProofTransactionData, _ handler: @escaping (TSDKBindingResponse<TSDKNoneResult, TSDKClientError>) throws -> Void | ||
) { | ||
let method: String = "proof_transaction_data" | ||
binding.requestLibraryAsync(methodName(module, method), payload) { (requestId, params, responseType, finished) in | ||
var response: TSDKBindingResponse<TSDKNoneResult, TSDKClientError> = .init() | ||
response.update(requestId, params, responseType, finished) | ||
try handler(response) | ||
} | ||
} | ||
|
||
} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,25 @@ | ||
public enum TSDKProofsErrorCode: Int, Codable { | ||
case InvalidData = 901 | ||
case ProofCheckFailed = 902 | ||
case InternalError = 903 | ||
case DataDiffersFromProven = 904 | ||
} | ||
|
||
public struct TSDKParamsOfProofBlockData: Codable { | ||
/// Single block's data, retrieved from TONOS API, that needs proof. Required fields are `id` and/or top-level `boc` (for block identification), others are optional. | ||
public var block: AnyValue | ||
|
||
public init(block: AnyValue) { | ||
self.block = block | ||
} | ||
} | ||
|
||
public struct TSDKParamsOfProofTransactionData: Codable { | ||
/// Single transaction's data as queried from DApp server, without modifications. The required fields are `id` and/or top-level `boc`, others are optional. In order to reduce network requests count, it is recommended to provide `block_id` and `boc` of transaction. | ||
public var transaction: AnyValue | ||
|
||
public init(transaction: AnyValue) { | ||
self.transaction = transaction | ||
} | ||
} | ||
|