CasperLabs releases Node 0.7
CasperLabs is pleased to announce the release of Node 0.7. Here we introduce usability features that simplify deployments and make the system easier to use, along with a new high-performance finality detector. The CasperLabs blockchain supports smart contracts that compile to WASM. Presently, compilation targets for Rust are available.
About this Release
The Scala client has been updated to take both the contract WASM bytes (or contract address) and a list of <name:value> pairs for arguments. This feature is available for both payment code as well as session code. For example, it is possible to have payment code where a 3rd party pays for deployments using a multi-sig wallet, and the account id for the multi-signatures could be passed in as deploy parameters.
For simpler transactions the node now supports ‘Standard Payment Code’ (sender pays) that is used as the default where no payment code is supplied for the deploy.
We have removed the nonce from deploys, with the introduction of persistent deploy buffers, these are no longer needed to prevent replay attacks or to order transactions.
Technical Details about this Release
Support for deploy command arguments
In previous releases, deploying a smart contract required that the calling dApp (first) hard-code arguments in the contracts (and then) precompile the contract (with arguments) into WASM. Further, there were 2 sets of WASM bytes required: one for payment code and one for session code. This design had two drawbacks: first, hardcoding arguments does not promote flexible application structure; and, the need to continually re-deploy the same basic contract is a waste of space on the chain.
This release addresses both of these usability issues. The deploy command can now accept a list of arguments for either (or both) of the payment and session contracts, as values of parameters — session-args and — payment-args. It is a more flexible interface for dApp developers to use, but the original interface also remains.
The list of arguments passed with — session-args and — payment-args should be a list of protobuf consensus.Arg objects serialized to Proto 3 JSON format, for example:
--session-args '[{"name": "amount", "value": {"long_value": 123456}}]For detailed documentation and more examples see CONTRACTS.md.
Additionally, payment and session contracts previously stored on the chain can be called by providing the hash, uref, or name of the contract. This cuts down on the amount of WASM passed and the amount of transaction data stored. The following is a list of parameters now available in the deploy subcommand:
-p, --payment <arg> Path to the file with payment code.--payment-hash <arg> Hash of the stored contract to be called in the payment; base16 encoded.--payment-name <arg> Name of the stored contract (associated with the executing account) to be called in the payment.--payment-uref <arg> URef of the stored contract to be called in the payment; base16 encoded.--private-key <arg> Path to the file with account private key (Ed25519)--public-key <arg> Path to the file with account public key (Ed25519)-s, --session <arg> Path to the file with session code.--session-hash <arg> Hash of the stored contract to be called in the session; base16 encoded.--session-name <arg> Name of the stored contract (associated with the executing account) to be called in the session.--session-uref <arg> URef of the stored contract to be called in the session; base16 encoded.
Deployment simplifications
Removal of Nonce
With the introduction of a persistent deploy buffer in the previous release, the nonce is no longer necessary to prevent replay attacks or guarantee sequential execution of conflicting deploys. The nonce has been removed from the API as well as from the Explorer, both the Scala and Python clients, GraphQL and the protobuf interfaces.
Standard Payment code as default
If no payment code is supplied for the deploy, CasperLabs will assume the use of the standard payment code. The standard payment code assumes that the calling account is the account paying for the execution of the payment and session contracts. The following represents the standard payment contract. More complex payment contracts are possible, but this captures the minimum behavior to satisfy the payment logic. The contract can be found in GitHub.
Deploy Selection Strategy
This release adds a basic deploy selection strategy with a block size limit. The strategy is to lazily consume a stream of Deploys from the DeployBuffer and send it to the Execution Engine and collect commuting effects until it reaches the end of the deploy stream or reaches block size limit. There's a config parameter max-block-size-bytes (or CLI parameter --casper-max-block-size-bytes) that allow user to set the maximum block size (default is 10MB).
A Faster Inspector: The Voting Matrix
The Voting matrix” is a high-performance implementation of The Inspector finality criterion. The main idea is that every validator maintains a mutable data structure reflecting the most recent knowledge on consensus establishing process. This structure is a square matrix N x N. where N is the number of validators. The Cell (i, ,j) in the matrix reflects the information “V(i) can see V(j) voting for consensus value P.
The matrix is updated:
- every time V creates a new message
- every time V receives a message from the network
The key improvement in the voting matrix algorithm (as opposed to the “reference” algorithm described in “The Inspector” spec) is the incremental nature of the processing. Instead of restarting the whole finality detection from scratch on every new message appearing in j-DAG, it keeps a mutable representation of the “finality situation” accumulated so far, and incrementally updates this information on every new message. This saves a lot of computation time.
The Voting matrix is an improvement over our current algorithm because it keeps the last known finalization score for each validator, for each DAG level in memory, which is continuously updated as new blocks are added. The finality of a block can be found more efficiently by looking up the current value in the matrix. The algorithm supports only acknowledgment level 1 (this is parameter K of finality detector specification).
Description of release packaging
Release packaging includes:
- Docker images available via DockerHub
- Debian package
- RPM package
- tar.gz
Where do developers go to learn more and get started?
At release, links to installation packages and relevant documentation is available on GitHub.
Where will bugs be filed?
Report a bug on GitHub
Where do developers go for support?
Join our community on Discord https://discord.gg/mpZ9AYD
About CasperLabs
CasperLabs is building a transformative blockchain for all applications that require a high degree of security, fast execution, and predictable economics. Our technology is built on the purest implementation of the proof-of-stake CBC-Casper protocol. We deliver a fully-decentralized, permissionless, public, and open source blockchain platform that supports developers with robust tools, application insights, and predictable fee structures.
