Sila SIPs

Slashing Protection Interchange Format

Tue, 27 Oct 2020 00:00:00 +0000

SIP #3076 - Slashing Protection Interchange Format is in Last Call status. It is authored by Michael Sproul (@michaelsproul), Sacha Saint-Leger (@sachayves), Danny Ryan (@djrtwo) and was originally created 2020-10-27. It is in the Interface category of type Standards Track. Please review and note any changes that should block acceptance.

The author has requested that discussions happen at the following URL: https://sila-magicians.org/t/sip-3076-validator-client-interchange-format-slashing-protection/4883

## Abstract A standard format for transferring a key's signing history allows validators to easily switch between clients without the risk of signing conflicting messages. While a common keystore format provides part of the solution, it does not contain any information about a key's signing history. For a validator moving their keys from client A to client B, this could lead to scenarios in which client B inadvertently signs a message that conflicts with an earlier message signed with client A. The interchange format described here provides a solution to this problem. ## Motivation The proof of stake (PoS) protocol penalises validators for voting in ways that could result in two different versions of the chain being finalised. These types of penalties are called slashings. For a validator following the protocol correctly, there is, in principle, no risk of being slashed. However, changing clients (from client A to client B, say) can result in a slashing risk if client B is unaware of the blocks and attestations that were signed with client A. This can occur if client A and client B do not agree on what the present time is. For example, say client A's time is accidentally set to a day in the future (225 epochs), and a validator switches from client A to client B without giving B a record of the blocks and attestations signed with A. The validator in question now runs the risk of attesting to two different blocks in the same epoch (a slashable offence) for the next 225 epochs (since they've already voted on these epochs with client A, and now stand to vote on them again with client B). Such time-skew bugs have been observed in the wild. Another situation in which slashing protection is critical is in the case of re-orgs. During a re-org it is possible for a validator to be assigned new attestation duties for an epoch in which it has already signed an attestation. In this case it is essential that the record of the previous attestation is available, even if the validator just moved from one client to another in the space of a single epoch. ## Specification ### JSON Schema A valid interchange file is one that adheres to the following JSON schema, and is interpreted according to the [Conditions](#conditions). ```json { "title": "Signing history", "description": "This schema provides a record of the blocks and attestations signed by a set of validators", "type": "object", "properties": { "metadata": { "type": "object", "properties": { "interchange_format_version": { "type": "string", "description": "The version of the interchange format that this document adheres to" }, "genesis_validators_root": { "type": "string", "description": "Calculated at Genesis time; serves to uniquely identify the chain" } }, "required": [ "interchange_format_version", "genesis_validators_root" ] }, "data": { "type": "array", "items": [ { "type": "object", "properties": { "pubkey": { "type": "string", "description": "The BLS public key of the validator (encoded as a 0x-prefixed hex string)" }, "signed_blocks": { "type": "array", "items": [ { "type": "object", "properties": { "slot": { "type": "string", "description": "The slot number of the block that was signed" }, "signing_root": { "type": "string", "description": "The output of compute_signing_root(block, domain)" } }, "required": [ "slot" ] } ] }, "signed_attestations": { "type": "array", "items": [ { "type": "object", "properties": { "source_epoch": { "type": "string", "description": "The attestation.data.source.epoch of the signed attestation" }, "target_epoch": { "type": "string", "description": "The attestation.data.target.epoch of the signed attestation" }, "signing_root": { "type": "string", "description": "The output of compute_signing_root(attestation, domain)" } }, "required": [ "source_epoch", "target_epoch" ] } ] } }, "required": [ "pubkey", "signed_blocks", "signed_attestations" ] } ] } }, "required": [ "metadata", "data" ] } ``` ### Example JSON Instance ```json { "metadata": { "interchange_format_version": "5", "genesis_validators_root": "0x04700007fabc8282644aed6d1c7c9e21d38a03a0c4ba193f3afe428824b3a673" }, "data": [ { "pubkey": "0xb845089a1457f811bfc000588fbb4e713669be8ce060ea6be3c6ece09afc3794106c91ca73acda5e5457122d58723bed", "signed_blocks": [ { "slot": "81952", "signing_root": "0x4ff6f743a43f3b4f95350831aeaf0a122a1a392922c45d804280284a69eb850b" }, { "slot": "81951" } ], "signed_attestations": [ { "source_epoch": "2290", "target_epoch": "3007", "signing_root": "0x587d6a4f59a58fe24f406e0502413e77fe1babddee641fda30034ed37ecc884d" }, { "source_epoch": "2290", "target_epoch": "3008" } ] } ] } ``` ### Conditions After importing an interchange file with data field `data`, a signer must respect the following conditions: 1. Refuse to sign any block that is slashable with respect to the blocks contained in `data.signed_blocks`. For details of what constitutes a slashable block, see `process_proposer_slashing` (from `consensus-specs`). If the `signing_root` is absent from a block, a signer must assume that any new block with the same `slot` is slashable with respect to the imported block. 2. Refuse to sign any block with `slot <= min(b.slot for b in data.signed_blocks if b.pubkey == proposer_pubkey)`, except if it is a repeat signing as determined by the `signing_root`. 3. Refuse to sign any attestation that is slashable with respect to the attestations contained in `data.signed_attestations`. For details of what constitutes a slashable attestation, see `is_slashable_attestation_data`. 4. Refuse to sign any attestation with source epoch less than the minimum source epoch present in that signer's attestations (as seen in `data.signed_attestations`). In pseudocode: ```python3 source.epoch < min(att.source_epoch for att in data.signed_attestations if att.pubkey == attester_pubkey) ``` {:start="5"} 5. Refuse to sign any attestation with target epoch less than or equal to the minimum target epoch present in that signer's attestations (as seen in `data.signed_attestations`), except if it is a repeat signing as determined by the `signing_root`. In pseudocode: ```python3 target_epoch <= min(att.target_epoch for att in data.signed_attestations if att.pubkey == attester_pubkey) ``` ### Additional Information - The `interchange_format_version` version is set to 5. - A signed block or attestation's `signing_root` refers to the message data (hash tree root) that gets signed with a BLS signature. It allows validators to re-sign and re-broadcast blocks or attestations if asked. - The `signed_blocks` `signing_root`s are calculated using `compute_signing_root(block, domain)`: where `block` is the block (of type `BeaconBlock` or `BeaconBlockHeader`) that was signed, and `domain` is equal to `compute_domain(DOMAIN_BEACON_PROPOSER, fork, metadata.genesis_validators_root)`. - The `signed_attestations` `signing_root`s are calculated using `compute_signing_root(attestation, domain)`: where `attestation` is the attestation (of type `AttestationData`) that was signed, and `domain` is equal to `compute_domain(DOMAIN_BEACON_ATTESTER, fork, metadata.genesis_validators_root)`. ## Rationale ### Supporting Different Strategies The interchange format is designed to be flexible enough to support the full variety of slashing protection strategies that clients may implement, which may be categorised into two main types: 1. **Complete**: a database containing every message signed by each validator. 2. **Minimal**: a database containing only the latest messages signed by each validator. The advantage of the minimal strategy is its simplicity and succinctness. Using only the latest messages for each validator, safe slashing protection can be achieved by refusing to sign messages for slots or epochs prior. On the other hand, the complete strategy can provide safe slashing protection while also avoiding false positives (meaning that it only prevents a validator from signing if doing so would guarantee a slashing). The two strategies are unified in the interchange format through the inclusion of [conditions](#conditions) (2), (4) and (5). This allows the interchange to transfer detailed or succinct information, as desired. ### Integer Representation Most fields in the JSON schema are strings. For fields in which it is possible to encode the value as either a string or an integer, strings were chosen. This choice was made in order to avoid issues with different languages supporting different ranges of integers (specifically JavaScript, where the `number` type is a 64-bit float). If a validator is yet to sign a block or attestation, the relevant list is simply left empty. ### Versioning The `interchange_format_version` is set to 5 because the specification went through several breaking changes during its design, incorporating feedback from implementers. ## Backwards Compatibility This specification is not backwards-compatible with previous draft versions that used version numbers less than 5. ## Security Considerations In order to minimise risk and complexity, the format has been designed to map cleanly onto the internal database formats used by implementers. Nevertheless, there are a few pitfalls worth illuminating. ### Advice for Complete Databases For implementers who use a complete record of signed messages to implement their slashing protection database, we make the following recommendations: - You MUST ensure that, in addition to importing all of the messages from an interchange, all the [conditions](#conditions) are enforced. In particular, conditions (2), (4) and (5) may not have been enforced by your implementation before adopting the interchange format. Our recommendation is to enforce these rules at all times, to keep the implementation clean and minimise the attack surface. For example: your slashing protection mechanism should not sign a block with a slot number less than, or equal to, the minimum slot number of a previously signed block, _irrespective_ of whether that minimum-slot block was imported from an interchange file, or inserted as part of your database's regular operation. - If your database records the signing roots of messages in addition to their slot/epochs, you should ensure that imported messages without signing roots are assigned a suitable dummy signing root internally. We suggest using a special "null" value which is distinct from all other signing roots, although a value like `0x0` may be used instead (as it is extremely unlikely to collide with any real signing root). - Care must be taken to avoid signing messages within a gap in the database (an area of unknown signing activity). This could occur if two interchanges were imported with a large gap between the last entry of the first and the first entry of the second. Signing in this gap is not safe, and would violate conditions (2), (4) and (5). It can be avoided by storing an explicit low watermark in addition to the actual messages of the slashing protection database, or by pruning on import so that the oldest messages from the interchange become the oldest messages in the database. ### Advice for Minimal Databases For implementers who wish to implement their slashing protection database by storing only the latest block and attestation for each validator, we make the following recommendations: - During import, make sure you take the _maximum_ slot block and _maximum_ source and target attestations for each validator. Although the [conditions](#conditions) require the minimums to be enforced, taking the maximums from an interchange file and merging them with any existing values in the database is the recommended approach. For example, if the interchange file includes blocks for validator `V` at slots 4, 98 and 243, then the latest signed block for validator `V` should be updated to the one from slot 243. However, if the database has already included a block for this validator at a slot greater than 243, for example, slot 351, then the database's existing value should remain unchanged. ### General Recommendations - To avoid exporting an outdated interchange file -- an action which creates a slashing risk -- your implementation should only allow the slashing protection database to be exported when the validator client or signer is _stopped_ -- in other words, when the client or signer is no longer adding new messages to the database. - Similarly, your implementation should only allow an interchange file to be imported when the validator client is stopped. ## Copyright Copyright and related rights waived via [CC0](/LICENSE).

SVM trace specification

Mon, 07 Dec 2020 00:00:00 +0000

SIP #3155 - SVM trace specification is in Last Call status. It is authored by Martin Holst Swende (@holiman), Marius van der Wijden (@MariusVanDerWijden) and was originally created 2020-12-07. It is in the Interface category of type Standards Track. Please review and note any changes that should block acceptance.

The author has requested that discussions happen at the following URL: https://sila-magicians.org/t/sip-3155-create-svm-trace-specification/5007

## Abstract Introduce a new JSON standard for SVM traces during execution of state tests. ## Motivation The Sila Virtual Machine executes all smart contract code on sila. In order to debug smart contracts and state tests better, a common format was introduced to log every execution step of the SVM. This format was implemented by Go-Sila, Parity-Sila, Nethermind and Besu. Since the common format was not well-defined, the implementations differed slightly, making it hard to develop adequate tooling which reduces the usefulness of tracing significantly. This SIP has multiple goals: - Move the specification to a more visible place to encourage new clients to implement it - Strictly define corner cases that were not addressed in the previous version - Allow for updates to the specification in case new fields are introduced during execution - Provide sample output Implementing this SIP in all major clients allows us to create meaningful differential fuzzers that fuzz SVM implementations for the sila-mainnet and all upcoming hardforks. It also helps to find differences in execution quickly in the case of a chain split. This SIP will enable users to create better differential fuzzing infrastructure to compare the SVM implementations of all major Sila clients against each other. This could help to find bugs that are currently present in the client implementations. ## Specification Clients should be able to execute simple transactions as well as code and return traces. In the following, we will call this client CUT (client under test) and use go-sila's `svm` binary for code examples. ### Datatypes | Type | Explanation | Example | |------------|----------------------------------------------------------------|---------------------| | Number | Plain json number | "pc":0 | | Hex-Number | Hex-encoded number | "gas":"0x2540be400" | | String | Plain string | "opName":"PUSH1" | | Hex-String | Hex-encoded string | | | Array of x | Array of x encoded values | | | Key-Value | Key-Value structure with key and values encoded as hex strings | | | Boolean | Json bool can either be true or false | "pass": true | ### Output The CUT MUST output a `json` object for EACH operation. #### Required Fields | Name | Type | Explanation | |--------------|----------------------|------------------------------------------| | `pc` | Number | Program Counter | | `op` | Number | OpCode | | `gas` | Hex-Number | Gas left before executing this operation | | `gasCost` | Hex-Number | Gas cost of this operation | | `memSize` | Number | Size of memory array | | `stack` | Array of Hex-Numbers | Array of all values on the stack | | `depth` | Number | Depth of the call stack | | `returnData` | Hex-String | Data returned by function call | | `refund` | Number | Amount of **global** gas refunded | #### Optional Fields | Name | Type | Explanation | |---------------|----------------------|---------------------------------------------------------------------| | `opName` | String | Name of the operation | | `error` | Hex-String | Description of an error (should contain revert reason if supported) | | `memory` | Array of Hex-Strings | Array of all allocated values | | `storage` | Key-Value | Array of all stored values | *Example:* ``` {"pc":0,"op":96,"gas":"0x2540be400","gasCost":"0x3","memory":"0x","memSize":0,"stack":[],"depth":1,"error":null,"opName":"PUSH1"} ``` - The `stack`, `memory` and `memSize` are the values *before* execution of the op. - All array attributes (`stack`, `memory`) MUST be initialized to empty arrays (`"stack":[]`) NOT to null. - If the CUT will not be outputting values for `memory` or `storage` then the `memory` and `storage` fields are omitted. This can happen either because the CUT does not support tracing these fields or it has been configured not to trace it. - The `memSize` field MUST be present regardless of `memory` support. - Clients SHOULD implement a way to disable recording the storage as the stateroot includes all storage updates. - Clients SHOULD output the fields in the same order as listed in this SIP. The CUT MUST NOT output a line for the `STOP` operation if an error occurred: *Example:* ``` {"pc":2,"op":0,"gas":"0x2540be3fd","gasCost":"0x0","memory":"0x","memSize":0,"stack":["0x40"],"depth":1,"error":null,"opName":"STOP"} ``` ### Summary and Error Handling At the end of execution, the CUT MUST print summary info; this info SHOULD have the following fields. The summary should be a single `jsonl` object. #### Required Fields | Name | Type | Explanation | |-------------|------------|--------------------------------------------------------| | `stateRoot` | Hex-String | Root of the state trie after executing the transaction | | `output` | | Return values of the function | | `gasUsed` | Hex-Number | All gas used by the transaction | | `pass` | Boolean | Bool whether transaction was executed successfully | #### Optional Fields | Name | Type | Explanation | |--------|--------|-------------------------------------------------------| | `time` | Number | Time in nanoseconds needed to execute the transaction | | `fork` | String | Name of the fork rules used for execution | *Example*: ``` {"stateRoot":"0xd4c577737f5d20207d338c360c42d3af78de54812720e3339f7b27293ef195b7","output":"","gasUsed":"0x3","pass":"true","time":141485} ``` ## Rationale This SIP is largely based on the previous non-official documentation for SVM tracing. It tries to cover as many corner cases as possible to enable true client compatibility. The datatypes and if a field is optional is chosen to be as compatible with current implementations as possible. ## Backwards Compatibility This SIP is fully backward compatible with sila as it only introduces a better tracing infrastructure that is optional for clients to implement. ### Clients This SIP is fully backward compatible with go-sila. Sila, Besu and Nethermind clients would have to change their JSON output of `sila-svm` `SVMtool` and `nethtest` slightly do adhere to the new and stricter specs. New clients would need to implement this change if they want to be part of the differential fuzzing group. ## Test Cases ```bash ${BESU_HOME}/bin/SVMtool --code 0x604080536040604055604060006040600060025afa6040f3 {"pc":0,"op":96,"gas":"0x2540be400","gasCost":"0x3","memSize":0,"stack":[],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":2,"op":128,"gas":"0x2540be3fd","gasCost":"0x3","memSize":0,"stack":["0x40"],"depth":1,"refund":0,"opName":"DUP1"} {"pc":3,"op":83,"gas":"0x2540be3fa","gasCost":"0xc","memSize":0,"stack":["0x40","0x40"],"depth":1,"refund":0,"opName":"MSTORE8"} {"pc":4,"op":96,"gas":"0x2540be3ee","gasCost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":[],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":6,"op":96,"gas":"0x2540be3eb","gasCost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40"],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":8,"op":85,"gas":"0x2540be3e8","gasCost":"0x4e20","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40","0x40"],"depth":1,"refund":0,"opName":"SSTORE"} {"pc":9,"op":96,"gas":"0x2540b95c8","gasCost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":[],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":11,"op":96,"gas":"0x2540b95c5","gasCost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40"],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":13,"op":96,"gas":"0x2540b95c2","gasCost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":15,"op":96,"gas":"0x2540b95bf","gasCost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40","0x0","0x40"],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":17,"op":96,"gas":"0x2540b95bc","gasCost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40","0x0","0x40","0x0"],"depth":1,"refund":0,"opName":"PUSH1"} {"pc":19,"op":90,"gas":"0x2540b95b9","gasCost":"0x2","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40","0x0","0x40","0x0","0x2"],"depth":1,"refund":0,"opName":"GAS"} {"pc":20,"op":250,"gas":"0x2540b95b7","gasCost":"0x24abb676c","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x40","0x0","0x40","0x0","0x2","0x2540b95b7"],"depth":1,"refund":0,"opName":"STATICCALL"} {"pc":21,"op":96,"gas":"0x2540b92a7","gasCost":"0x3","memory":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b00000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x1"],"returnData":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b","depth":1,"refund":0,"opName":"PUSH1"} {"pc":23,"op":243,"gas":"0x2540b92a4","gasCost":"0x0","memory":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b00000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memSize":96,"stack":["0x1","0x40"],"returnData":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b","depth":1,"refund":0,"opName":"RETURN"} {"stateRoot":"0x8fa0dcc7f1d2383c89e5737c2843632db881c0946e80b71fe7175365e6538797","output":"0x40","gasUsed":"0x515c","pass":true,"fork":"Istanbul"} ``` ## Security Considerations Tracing is expensive. Exposing an endpoint for creating traces publicly could open up a denial of service vector. Clients should consider putting trace endpoints behind a separate flag from other endpoints. ## Copyright Copyright and related rights waived via [CC0](/LICENSE).

Empty accounts deprecation

Tue, 19 Sep 2023 00:00:00 +0000

SIP #7523 - Empty accounts deprecation is in Last Call status. It is authored by Peter Davies (@petertdavies) and was originally created 2023-09-19. It is in the Core category of type Standards Track. Please review and note any changes that should block acceptance.

The author has requested that discussions happen at the following URL: https://sila-magicians.org/t/sip-7523-empty-accounts-deprecation/15870

## Abstract This SIP prohibits the state of any post-merge network from containing empty accounts. Since no empty accounts exist outside the testsuite and no new ones can be created this requirement is already achieved in practice. An explicit ban reduces technical debt going forward. ## Motivation The possibility of empty accounts is a historical artifact of the early history of Sila. The only networks that have ever been capable of containing them are Sila SilaMainnet, the deprecated testnet Ropsten, Etheruem Classic SilaMainnet and various Sila Classic testnets. All remaining empty accounts on SilaMainnet were cleared in block `14049881` (transaction `0xf955834bfa097458a9cf6b719705a443d32e7f43f20b9b0294098c205b4bcc3d`) and a similar transaction was sent on Sila Classic. None of the other myriad SVM-compatible networks are old enough to have empty accounts and there is no realistic prospect that anyone will encounter an empty account in a production context. Despite empty accounts no longer existing, they still impose a legacy of technical debt. [SIP-161](/SIPS/sip-161) imposes complicated rules that require a client to delete an empty account when it is "touched". As the Sila specification continues to evolve new edgecases of the "touch" rules arise which must be debated, implemented, tested and documented. If a future client wishes to only support post-merge blocks it must implement unnecessary empty account support solely to pass the test suite. By prohibiting empty accounts on post-merge networks, this SIP frees designers and implementers of Sila and related blockchains from the burden of having to consider them going forward. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. An empty account is an account with has **no code** and **zero nonce** and **zero balance**. This is the same as the definition in [SIP-161](/SIPS/sip-161). On networks that undergo the merge transition, the pre state of the merge block may not contain any empty accounts. For networks that are merged at genesis, none of the genesis accounts may be empty accounts. Rather than performing a scan of the state, clients MAY assume the following chains have no post-merge empty accounts: 1. The SilaMainnet chain whose merge block has hash `0x56a9bb0302da44b8c0b3df540781424684c3af04d0b7a38d72842b762076a664`. 2. Any chain which satisfies all of the following: - has no empty accounts in the genesis. - had a post Spurious Dragon fork at genesis. The Sila specification is declared to be undefined in the presence of an empty account in a post-merge context. Any testcase involving post-merge empty accounts is invalid. ## Rationale This SIP was drafted to be the simplest possible way of eliminating the long term technical debt imposed by empty accounts. The Merge was chosen as a natural easily identifiable cutoff point. Alternative approaches include: - Using an earlier cutoff point, such as block `14049881`. - Identifying a wider range of edge case behaviour that never happened. These approaches were rejected as being unnecessarily complicated. ## Backwards Compatibility As SIP does not change any behaviour that can occur outside the testsuite, it has no backwards compatibility consequences. ## Security Considerations The validity of this SIP is dependent on the assertion that all empty accounts on Sila SilaMainnet were cleared prior to the merge. This should be subject to appropriate verification. Any networks artificially created with empty accounts will cause problems with tooling and clients. ## Copyright Copyright and related rights waived via [CC0](/LICENSE).

Revert creation in case of non-empty storage

Fri, 02 Feb 2024 00:00:00 +0000

SIP #7610 - Revert creation in case of non-empty storage is in Last Call status. It is authored by Gary Rong (@rjl493456442), Martin Holst Swende (@holiman) and was originally created 2024-02-02. It is in the Core category of type Standards Track. Please review and note any changes that should block acceptance.

The author has requested that discussions happen at the following URL: https://sila-magicians.org/t/sip-revert-creation-in-case-of-non-empty-storage/18452

## Abstract This SIP causes contract creation to throw an error when attempted at an address with pre-existing storage. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. If a contract creation is attempted due to a creation transaction, the `CREATE` opcode, the `CREATE2` opcode, or any other reason, and the destination address already has either a nonzero nonce, a nonzero code length, or non-empty storage, then the creation MUST throw as if the first byte in the init code were an invalid opcode. This change MUST apply retroactively for all existing blocks. This SIP amends [SIP-684](/SIPS/sip-684) with one extra condition, requiring empty storage for contract deployment. This SIP will not affect [SIP-7702](/SIPS/sip-7702), since the authority's nonce is always incremented after an authorization is applied, which conflicts with the condition required for contract deployment. ## Rationale SIP-684 defines two conditions for contract deployment: the destination address must have zero nonce and zero code length. Unfortunately, this is not sufficient. Before [SIP-161](/SIPS/sip-161) was applied, the nonce of a newly deployed contract remained set to zero. Therefore, it was entirely possible to create a contract with a zero nonce and zero code length but with non-empty storage, if slots were set in the constructor. There exists 28 such contracts on Sila sila-mainnet at this time. ## Backwards Compatibility This is an execution layer upgrade, and so it requires a hard fork. ## Test Cases There exists quite a number of tests in the sila tests repo as well as in the execution spec tests, which test the scenario of deployment to targets with non-empty storage. These tests have been considered problematic in the past; Reth and EELS both intentionally implement a version of the account reset solely to pass the tests. Py-svm declared the situation impossible and never implemented account reset. Refilling the existing tests will provide sufficient coverage for this SIP. ## Security Considerations This SIP is a security upgrade: it enforces the immutability of deployed code. ## Copyright Copyright and related rights waived via [CC0](/LICENSE).

Network Upgrade Inclusion Stages

Wed, 12 Jun 2024 00:00:00 +0000

SIP #7723 - Network Upgrade Inclusion Stages is in Last Call status. It is authored by Tim Beiko (@timbeiko), Alex Stokes (@ralexstokes), Ansgar Dietrichs (@adietrichs), Nixo (@nixorokish), Parithosh Jayanthi (@parithosh) and was originally created 2024-06-12. It is in the category of type Meta. Please review and note any changes that should block acceptance.

The author has requested that discussions happen at the following URL: https://sila-magicians.org/t/sip-7723-network-upgrade-inclusion-stages/20281

## Abstract Defines the stages that SIPs go through in the process of planning network upgrades: `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included`. ## Motivation This SIP proposes definitions for the various stages SIPs go through when planning network upgrades. It also provides context and guidelines around when and how SIPs should be moved from one stage to the next. ## Specification The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174. All SIP stages apply to a single network upgrade. SIPs must be `Proposed`, `Considered`, `Declined` or `Scheduled` separately for each network upgrade. While an SIP cannot be `Included` in two network upgrades, an SIP being `Declined for Inclusion` in a previous upgrade does not prevent it from being `Proposed`, `Considered`, `Declined` or `Scheduled` for inclusion in any future upgrade. The stages below are generally defined for Standards Track - Core SIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core SIPs may also be assigned these stages. The differences in the process and implications for non-Core SIPs are noted in each stage's definition. ### Upgrade Meta SIPs Anyone **MAY** draft a Meta SIP to list SIPs for a network upgrade. This Meta SIP **SHOULD** include four categories in its specification section: `Proposed for Inclusion`, `Declined for Inclusion`, `Considered for Inclusion` and `Scheduled for Inclusion`. Even if a category is `TBD`, it **SHOULD** be included in the initial draft for clarity. When the Upgrade Meta SIP is moved to `Review`, the `Proposed for Inclusion` and the `Declined for Inclusion` list **SHOULD** be removed. When it is moved to `Last Call`, `Considered for Inclusion` lists **SHOULD** be removed, leaving only the `Scheduled for Inclusion` list. Before the Upgrade Meta SIP is moved to `Final`, the `Scheduled for Inclusion` stage **MUST** be renamed to `Included` and contain only SIPs that were activated with the upgrade. ### Upgrade Devnets When preparing a network upgrade, client developers typically implement SIPs first on an ephemeral test network (upgrade devnet) to verify client interoperability before deploying to long-lived test networks. These upgrade devnets follow a naming convention of `upgradeName-devnet-version` (e.g. `pectra-devnet-0` for the first upgrade devnet of the Pectra network upgrade, `dencun-devnet-1` for the second upgrade devnet of the Dencun update, etc). Since client developers' ability to include SIPs in a network upgrade is constrained by what can be implemented and tested in these upgrade devnets, the [Considered for Inclusion](#considered-for-inclusion) and [Scheduled for Inclusion](#scheduled-for-inclusion) sections below propose aligning these statuses with SIPs' implementation status in upgrade devnets. ### Proposed for Inclusion To propose an SIP for inclusion, someone **MUST** open a pull request to add it to the `Proposed for Inclusion` (PFI) section of the Upgrade Meta SIP. The proposer of an SIP **SHOULD** serve as the primary point of contact for that SIP for the duration of the upgrade cycle or **SHOULD** designate another person to serve in that role. Reasonable pull requests **SHOULD** be merged in a timely fashion by the Upgrade Meta SIP author. At this stage, implementation teams **SHOULD** review the SIP. For Core SIPs, this should be in the context of including it in the said upgrade. For non-Core SIPs, this should be in the context of supporting Core SIPs before the network upgrade is activated. Note that SIPs must be `Proposed for Inclusion` for each network upgrade. In other words, proposals do not "carry over" to the next upgrade if an SIP is not included in the one it was first proposed for. ### Considered for Inclusion Once client developers have reviewed an SIP which was `Proposed for Inclusion`, they **MAY** move it to the `Considered for Inclusion` (CFI) stage. Once a decision is made by client teams to move an SIP to `Considered for Inclusion`, the Upgrade Meta SIP **SHOULD** be updated to reflect this. `Considered for Inclusion` signals that client developers intend to attempt to include the SIP in devnets. The All Core Devs Execution (ACDE) and Consensus (ACDC) call facilitators should work with the testing teams to propose a priority ordering of CFI SIPs to be reviewed by client developers, and then reflect this prioritization in the Meta SIP. This prioritization should inform which SIPs should be included in upcoming devnets, with some flexibility if circumstances change. Assuming it meets all the requirements for sila-mainnet deployment it **MAY** be included in the network upgrade. This stage is similar to "concept ACK" in other open source projects, and is not sufficient to result in deployment to sila-mainnet. Non-Core SIPs that are `Considered for Inclusion` **SHOULD** be supported prior to the network upgrade being activated. An SIP **MAY** be moved from `Considered for Inclusion` to `Declined for Inclusion` if client teams are against including the SIP in the network upgrade. An SIP **SHOULD** have a Python implementation accompanied by tests in [execution-specs](https://github.com/sila-chain/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md) submitted as an open PR. The SIP writer is encouraged to reach out to the maintainers of execution-specs for assistance with implementation. Client developers **MAY** decide to allow an SIP to be moved to `Considered for Inclusion` without either implementation, being aware that the absence of these implementations could lead to delays in the testing cycle. Any updates to an SIP that is already at this stage **SHOULD** be accompanied by the appropriate updates to its implementation and tests in [execution-specs](https://github.com/sila-chain/execution-specs/blob/78fb726158c69d8fa164e28f195fabf6ab59b915/README.md) if deemed necessary by client developers. ### Declined for Inclusion At any time during the network upgrade planning process, client developers **MAY** move SIPs from any other stage to the `Declined for Inclusion` (DFI) stage if client teams are against including the SIP in the network upgrade. Once a decision is made by client teams to move an SIP to `Declined for Inclusion`, the Upgrade Meta SIP **SHOULD** be updated to reflect this. `Declined for Inclusion` signals that client developers wish to exclude the SIP from the current network upgrade and stop discussing its potential inclusion or implementation status in relation to this upgrade. An SIP which was `Declined for Inclusion` in a particular upgrade **MAY** still be `Proposed for Inclusion` in a subsequent upgrade. In exceptional circumstances, client developers **MAY** choose to move an SIP from `Declined for Inclusion` to `Considered for Inclusion` or `Scheduled for Inclusion`. ### Scheduled for Inclusion An SIP can be moved to Scheduled for Inclusion (SFI) when core developers: 1. Agree upon a strong intent to include the SIP in the next network upgrade. 2. Agree that an SIP's specifications and implementations have reached a certain level of maturity. I.e., an SFI status signals that the SIP is on track for inclusion barring unforeseen issues. The following critieria can be applied to ascertain whether an SIP is mature (stable) enough to move to SFI: - It has been included in a devnet that has demonstrated stability (e.g., high participation, no critical bugs for ≥1 week). - The SIP specification is close to final (no placeholder values or pending design decisions). - It has minimal interactions with other CFI SIPs, OR those interactions have been tested in the same devnet. - Testing coverage is adequate (clients pass consensus tests, no known divergence across clients). All Core Devs Testing (ACDT) calls may review SIPs to determine SFI eligibility. Status changes will then be ratified on ACDE or ACDC before assigning SFI status. `Scheduled for Inclusion` signals that the SIP is on track for inclusion barring unforeseen issues. SIPs with incomplete specs or untested interactions should remain CFI until these conditions are met. The latest Upgrade Devnet must contain all `Scheduled for Inclusion` Core SIPs. An SIP **MAY** be moved from `Scheduled for Inclusion` to `Declined for Inclusion` if circumstances necessitate removal, as agreed by client teams. An SIP **MAY** also be moved from `Scheduled for Inclusion` to `Considered for Inclusion` if client teams remain in favor of including the SIP in the network upgrade but cannot commit to including it in the **next** Upgrade Devnet. An SIP **MUST** have a Python implementation accompanied by tests in [execution-specs](https://github.com/sila-chain/execution-specs/blob/5cdb055e069e246a877c8aa018079eb0b9093f57/README.md), submitted as an open PR or merged to the `devnets/upgradeName/version` branch of the repository. Client developers **MAY** decide to allow an SIP to be moved to `Scheduled for Inclusion` without an [execution-specs](https://github.com/sila-chain/execution-specs/blob/5cdb055e069e246a877c8aa018079eb0b9093f57/README.md) implementation, but the tests are strictly mandatory. Any updates to an SIP that is already at this stage **MUST** be accompanied by appropriate updates to its implementation and tests in [execution-specs](https://github.com/sila-chain/execution-specs/blob/5cdb055e069e246a877c8aa018079eb0b9093f57/README.md) if deemed necessary by client developers. ### Included After network upgrade activation, all included Core SIPs and activated non-Core SIPs **MUST** be moved to `Included` in the Meta SIP. All other status lists **MUST** be removed from the Meta SIP. `Included` signals that the SIPs have been activated as part of the network upgrade. ## Rationale Formalizing the `Proposed for Inclusion`, `Considered for Inclusion`, `Scheduled for Inclusion`, `Declined for Inclusion` and `Included` stages provides better legibility to both protocol maintainers and the broader Sila community. The specification tries to minimize steps that **MUST** be followed to align with Sila's "rough consensus" governance model. Assuming it is adopted, the process outlined in this SIP should be used for at least one full network upgrade cycle before moving to `Last Call` and at least two full network upgrade cycles before moving to `Final`. This way, the SIP can be updated to reflect changes made to the process over time. ## Backwards Compatibility This SIP does not directly change the Sila protocol. It formalizes parts of the current network upgrade planning process. ## Security Considerations None. ## Copyright Copyright and related rights waived via [CC0](/LICENSE).