Feat/explicit-contract-version #3192
Merged
Conversation
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
…ion, and use that version (not the epoch) when starting transactions
… version of clarity to use (i.e. don't use the epoch anymore)
…with the current epoch
… majority of lines changed in this particular commit)
…act or calls an existing one, deduce which version of Clarity to use. For smart contracts, use the one indicated in the transaction payload if given, or use the epoch-defined default if not. For contract-calls, load up the target contract's clarity version.
…sion, which represents a new transaction type in which an explicit version can be given
…ls can call into contracts with different versions, and everything will work out
… so we know what parsing, analysis, and runtime rules to apply
…nal test coverage to ensure that new 2.1 transaction variants cannot occur in blocks until after 2.1
…of different clarity versions, and with trait definitions and implementations in different clarity versions
…er take a clarity version; instead, analyze_smart_contract() and initialize_smart_contract*() methods take a clarity version directly
…ransaction; this is only needed for smart contract instantiation
…-only. Use OwnedEnvironment::new_versioned_contract() from now on, and explicitly specify a Clarity version to use
This was referenced Aug 17, 2022
Closed
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This addresses #3131 and #2719, as well as #2609. It introduces a
SmartContractpayload variant that takes an explicit Clarity version, so that post-2.1 developers can require that the contract adhere to Clarity 1 or Clarity 2 rules. If they do not do so, then the epoch default Clarity version is used (which will be Clarity 2 in 2.1).The PR removes most uses of
ClarityVersion::default_for_epoch()and replaces them with a transaction-supplied Clarity version. When a transaction is processed, a new methodStacksChainState::get_tx_clarity_version()is called to deduce which version of Clarity to supply the Clarity VM. The rules are as follows:This PR tests #2719 by addressing #3131. It introduces a "torture test" for cross-contract and cross-Clarity-version contract calls in
chainstate::stacks::tests::block_construction::test_contract_call_across_clarity_versions. It verifies the following:The method invoked by a contract call transaction runs with the Clarity version that the contract that defined it used. So for example, a Clarity1 contract can call a Clarity2 contract function, and that Clarity2 function can do Clarity2-specific things.
The method invoked by an explicit
contract-call?follows the above rule as well.A trait defined in Clarity1 can be implemented by a Clarity2 contract.
A trait defined in Clarity2 can be implemented by a Clarity1 contract.
Dynamic dispatches to traits will run with the Clarity version of the trait implementation. So for example, if a Clarity1 contract calls into a trait that, regardless of the trait definition's Clarity version, has a Clarity2 implementation, then the dispatch will run in Clarity2.
The closure of an
(at-block)will run with the Clarity version in which it is defined, like any other code statement. Similarly, contract-calls within the at-block will run in the target method's contract's Clarity version.The PR addresses #2609 by ensuring that a block will not be processed if it contains 2.1-only transactions, such as pay-to-alt-principal coinbases and explicit-version smart contracts. This gating logic not only applies in block validation (which covers both the blockchain-processing and miner), but also in mempool acceptance.