-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #132 from casper-ecosystem/teonite
Teonite
- Loading branch information
Showing
6 changed files
with
228 additions
and
0 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
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,50 @@ | ||
| --- | ||
| Grant-Number: "N/A", | ||
| Name: "Smart Contract Source Code Verification Service", | ||
| Service-Provider: "", | ||
| Status: "In progress", | ||
| Grant-Link: "", | ||
| Website: "https://teonite.com/", | ||
| Grant-Size: "Large", | ||
| Total-Milestones: "5", | ||
| Current-Milestone: "M1", | ||
| M1: "11.09.2023","In progress", | ||
| M2: "25.09.2023","To do", | ||
| M3: "02.10.2023","To do", | ||
| M4: "14.08.2023","To do", | ||
| M5: "21.08.2023","To do", | ||
| Twitter: "", | ||
| Public-Project-Chat: "", | ||
| Casper-PM: "https://github.com/piotr-dziubecki", | ||
| Project-GitHub-Repo: "", | ||
| --- | ||
| <!--lang:en--> | ||
| CSPR Live Block Explorer (or in fact any other Casper open-source block explorers) do not implement any services for smart contracts source code and deployment validation or smart contract source code browsing and interacting. | ||
| Our aim is to create: | ||
| a) source code storage, validation, and browsing service that will expose an API for interacting with any service that would like to incorporate this functionality (CSPR Live or any other block explorer) and will have enterprise-grade security (with Hardware Security Modules - HSM - proposed: Nitro HSM 2) | ||
| b) distributed build system supporting a defined library of Rust compilers and casper-contract smart contract library versions in order to quickly produce WASM builds for further validation | ||
| c) extend casper-client (as a pull request) with functionalities for submitting the source code to the validation service | ||
| d) example web service (and React components library) - that will use the validation service and based on the submitted deploy hash can state if the deployment is validated - if so, enable to browsing the validated deploy source code | ||
| All milestones are in detailed outlined (and calculated in terms of budget and schedule) based on the following Work Breakdown Structure: | ||
| https://docs.google.com/spreadsheets/d/14FUmM3eBE2Gx10eGbtxVqkH7nC8QUEGN3KglSJdru1U | ||
| Smart Contract source code validation and browsing is a core and fundamental functionality in any block explorer (already implemented in various blockchains) - but Casper is lacking it. | ||
| The deployment code browsing is also critical for end users in terms of building trust, transparency, and peace of mind for anyone that would like to interact with the deployed smart contract - as they can read the code. | ||
| But there also is a huge opportunity in building a service that will have access to all smart contracts source codes (and validations), that will be the foundation for future additional services, like: | ||
| contract history (changes over time) view - what has changed over a selected time span | ||
| developer validation service - since Casper is an enterprise blockchain it would be of much value to implement the functionality of developer validation, exposing not only the source code validation but also detailed information about the developer who is responsible for the deployment (and source code). | ||
| Developer validation functionality can be simple - eg. enable the developer to sign the validated source code with the same private key (as the deployment) matching and verifying that the deployment is done by the same developer that submitted the validation - but also can implement KYC for developer validation, organization validation - enabling potential premium services like get detailed information of developer/organization responsible for the deployment | ||
| AI/Machine Learning service for analyzing the source code to find scams and suspicious smart contracts (based on source code, and reports from security companies that did the code validation and testing) | ||
| data statistics and analytics on the source code | ||
| premium validation services that could expose security analysis (which the security researcher has audited the source code, and access to security report data) | ||
|
|
||
| <!--lang:es--] | ||
| <!--lang:de--] | ||
| <!--lang:fr--] | ||
| <!--lang:pl--] | ||
| <!--lang:uk--] | ||
| [!--lang:*--> |
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,80 @@ | ||
| --- | ||
| Milestone: "M1", | ||
| Status: "In progress", | ||
| --- | ||
| <!--lang:en--> | ||
| ### Description | ||
|
|
||
| There is a well-known issue that could impact the feasibility of creating a smart contract verification service for Casper Network - the WASM deployment on the blockchain is pre-processed on the node, meaning the WASM binary on-chain is not the same as the one uploaded by the developer. | ||
|
|
||
| This is an RnD (Reasearch & Development) milestone and the goal is to tackle this critical issue and recreate or reverse the pre-processing to compare with the binary created by compiling the source code. | ||
| Our analysis shows (please see the detailed analysis chapter below: WASM binary processing analysis), that we should be able to recreate the binary optimization process performed on the blockchain node while executing the finalized block but that needs actual RnD work to confirm it (or state otherwise) - thus this milestone. | ||
|
|
||
| There also was uncertainty about the Rust compiler itself producing deterministic builds - but from our research code translation methods are now based on pseudocode for a very long time - in other words, the compiler works deterministically by translating to its higher-level pseudocode, optimizing it and then switching to real asm. | ||
|
|
||
|
|
||
| ### Acceptance Criteria | ||
|
|
||
| Deliverables: | ||
|
|
||
| 1. Recreate the binary optimization process performed on the blockchain node while executing the finalized block with a Rust crate and a simple command line tool that uses the same mechanisms as the casper-node. | ||
|
|
||
| 2. Create tests that will either prove that it’s possible to produce the same WASM build as the node does or will fail and state there is no possibility to do so without chaining the node/core CSPR services. | ||
|
|
||
| If the reproduction process succeeds - next milestones are valid, if the reproduction process and tests fail next milestones will not be realized. | ||
|
|
||
|
|
||
|
|
||
| WASM binary processing analysis | ||
| Below is a general description of how the smart contract binary is processed within the system before being stored on the blockchain. The analysis is based on the latest releases of relevant components: | ||
| casper-node v1.5.0-rc.1 (a50b85a) | ||
| casper-client-rs v1.6.0 (63a311a) | ||
| casper-wasm-utils v1.0.0 (035ba8c) | ||
| WASM/Deploy processing flow | ||
| developer compiles smart contract source code into a .wasm file | ||
| developer sends the binary to a node as part of a Deploy by using the casper-client CLI | ||
| https://docs.casper.network/resources/quick-start/ | ||
| the client attaches the binary as-is and sends the Deploy to a JSON-RPC endpoint on the specified node | ||
| https://github.com/casper-ecosystem/casper-client-rs/blob/63a311afbd3e29d3424b4eb2f620468603a17510/lib/parsing.rs#L507 | ||
| https://github.com/casper-ecosystem/casper-client-rs/blob/63a311afbd3e29d3424b4eb2f620468603a17510/lib/parsing.rs#L606 | ||
| request is received and RpcServerAnnouncement::DeployReceived event is added to API event queue; the event is actually immediately converted to Event::Accept type associated with MainReactor | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/rpc_server.rs#L275 | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor/event.rs#L103 | ||
| DeplyAcceptor receives a new Deploy and verifies it complies with chain configuration and is not expired | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L241 | ||
| DeplyAcceptor fetches highest block header and account associated with deploy from storage; this data is used to check if given account is authorized to submit the deploy (has sufficient weight, matches with required approvals) | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L284 | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L326 | ||
| DeplyAcceptor checks if account main purse balance is sufficient to pay for the Deploy | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L398 | ||
| DeplyAcceptor validates payment and session logic | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L457 | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L577 | ||
| DeplyAcceptor validates cryptographic signatures of a Deploy | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L841 | ||
| Deploy is put to storage | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L859 | ||
| new Deploy announcement is put in event queue and a response is sent to JSON-RPC client | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L905 | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/deploy_acceptor.rs#L930 | ||
| new Deploy is gossipped to peers | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/gossiper.rs#L83 | ||
| consensus mechanism works to finalize a block | ||
| the finalized block is executed by the execution engine | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/consensus/era_supervisor.rs#L1043 | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/node/src/components/contract_runtime/operations.rs#L92 | ||
| at this point, the WASM binary used by the execution engine is the same one that the user submitted | ||
| to install the contract the binary contains a bit of session code (the call method) which defines the entrypoints and calls the new_contract method which is actually an FFI call to a host function provided by the Execution Engine | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/smart_contracts/contract/src/contract_api/storage.rs#L100 | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/execution_engine/src/core/runtime/externals.rs#L583 | ||
| the host function generates new WASM binary with only the relevant entry point methods included (stripping the call method itself and any unused methods from the user-provided binary) | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/execution_engine/src/core/runtime/mod.rs#L1663 | ||
| https://github.com/casper-network/casper-wasm-utils/blob/master/src/optimizer.rs#L16 | ||
| this modified binary is the one that is actually stored in global state | ||
| https://github.com/casper-network/casper-node/blob/a50b85a910a4c49b60e5cb2402de336d85aff6c6/execution_engine/src/core/runtime/mod.rs#L1693 | ||
|
|
||
|
|
||
| ### Progress Update | ||
|
|
||
| **Reporting Period: 17.08.2023 - 17.08.2023** | ||
|
|
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,27 @@ | ||
| --- | ||
| Milestone: "M2", | ||
| Status: "To do", | ||
| --- | ||
| <!--lang:en--> | ||
| ### Description | ||
|
|
||
| The next stage of the critical path in delivering the service is the build system that will enable to: | ||
| do distribute builds in order to support asynchronous builds for scaling the service | ||
| support various versions of Rust compilers for builds - we don’t know which Rust compiler version the developer will use - and there is a possibility (to be checked in the milestone) that various different Rust versions will produce slightly different WASM bytecode - thus the verification on-chain would fail - thus the build system needs to support multiple versions | ||
| support various versions of casper-library (same as above) | ||
| use the reproducible WASM deployment mechanism from the previous milestone | ||
|
|
||
|
|
||
|
|
||
| ### Acceptance Criteria | ||
|
|
||
| A microservice (or microservices) based on Docker with API | ||
| Code should be delivered in Rust | ||
| Microservice is secure (define authentication and authorization for the build microservice) and executes jobs to build Smart Contracts from source code | ||
| As a result, WASM bytecode should be the result with all required metadata about the build details (versions, libraries, etc) | ||
|
|
||
|
|
||
| ### Progress Update | ||
|
|
||
| **Reporting Period: 17.08.2023 - 17.08.2023** | ||
|
|
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,27 @@ | ||
| --- | ||
| Milestone: "M3", | ||
| Status: "To do", | ||
| --- | ||
| <!--lang:en--> | ||
| ### Description | ||
|
|
||
| Having reproducible and coherent builds done, next the public validation service will be implemented with the following functionalities: source code storage, code validation, and REST API to communicate with the service. | ||
|
|
||
|
|
||
| ### Acceptance Criteria | ||
|
|
||
| a web proxy (public) microservice implementing: | ||
| authentication and authorization for end users to be able to communicate with the service | ||
| REST API of the service with RUST DOC documentation of the service and/or OpenAPI 3.x document specification | ||
|
|
||
| Storage microservices - that will store all relevant data: | ||
| source code with all metadata information (developer, dates, etc.) | ||
| WASM builds with all data from the distributed build system (metadata, build logs, etc.) | ||
| validation data - cryptographic data of Smart Code Validation with all data (logs of that operation, etc.) | ||
|
|
||
| Validation microservice - a microservice written in Rust and integrated with Hardware Security Modules (initially with Nitrokey HSM 2 security module) that will implement cryptographic operations for Source Code and WASM bytecode validation and produce validation data | ||
|
|
||
| ### Progress Update | ||
|
|
||
| **Reporting Period: 17.08.2023 - 17.08.2023** | ||
|
|
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,24 @@ | ||
| --- | ||
| Milestone: "M4", | ||
| Status: "To do", | ||
| --- | ||
| <!--lang:en--> | ||
| ### Description | ||
|
|
||
| A command line reference client implementation for integrating with the validation service as a pull request to casper-client. | ||
|
|
||
|
|
||
|
|
||
| ### Acceptance Criteria | ||
|
|
||
| Rust crate with the integration done in casper-client (as a GitHub pull request) | ||
| Authentication with the service | ||
| Submitting the source code for validation (the result with Job ID as it should be asynchronous) | ||
| Possibility to get the validation status from Job ID | ||
| Documentation in Rust Doc | ||
|
|
||
|
|
||
| ### Progress Update | ||
|
|
||
| **Reporting Period: 17.08.2023 - 17.08.2023** | ||
|
|
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,20 @@ | ||
| --- | ||
| Milestone: "M5", | ||
| Status: "To do", | ||
| --- | ||
| <!--lang:en--> | ||
| ### Description | ||
|
|
||
| Example web page that will enable the user to input a deployment from mainnet and: | ||
| See if it’s validated or not | ||
| If validated see the source code | ||
|
|
||
| ### Acceptance Criteria | ||
|
|
||
| React component as a library that can be used in other React pages that enables one to use it and style it accordingly to the web page (cspr.live from what we see uses React). It will automatically display if the deployment is validated or not, and if it is - it will show a source code browser. | ||
|
|
||
|
|
||
| ### Progress Update | ||
|
|
||
| **Reporting Period: 17.08.2023 - 17.08.2023** | ||
|
|