ethereum authorization

motivation on-chain deployed evm bytecode contains no pre-defined structure today. code is typically validated in clients to the extent of jumpdest analysis at runtime, every single time prior to execution. this poses not only an overhead, but also a challenge for introducing new or deprecating existing features. validating code during the contract creation process allows code versioning without an additional version field in the account. versioning is a useful tool for introducing or deprecating features, especially for larger changes (such as significant changes to control flow, or features like account abstraction). the format described in this eip introduces a simple and extensible container with a minimal set of changes required to both clients and languages, and introduces validation. the first tangible feature it provides is separation of code and data. this separation is especially beneficial for on-chain code validators (like those utilised by layer-2 scaling tools, such as optimism), because they can distinguish code and data (this includes deployment code and constructor arguments too). currently, they a) require changes prior to contract deployment; b) implement a fragile method; or c) implement an expensive and restrictive jump analysis. code and data separation can result in ease of use and significant gas savings for such use cases. additionally, various (static) analysis tools can also benefit, though off-chain tools can already deal with existing code, so the impact is smaller. a non-exhaustive list of proposed changes which could benefit from this format: including a jumpdest-table (to avoid analysis at execution time) and/or removing jumpdests entirely. introducing static jumps (with relative addresses) and jump tables, and disallowing dynamic jumps at the same time. multibyte opcodes without any workarounds. representing functions as individual code sections instead of subroutines. introducing special sections for different use cases, notably account abstraction. 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. in order to guarantee that every eof-formatted contract in the state is valid, we need to prevent already deployed (and not validated) contracts from being recognized as such format. this is achieved by choosing a byte sequence for the magic that doesn’t exist in any of the already deployed contracts. remarks the initcode is the code executed in the context of the create transaction, create, or create2 instructions. the initcode returns code (via the return instruction), which is inserted into the account. see section 7 (“contract creation”) in the yellow paper for more information. the opcode 0xef is currently an undefined instruction, therefore: it pops no stack items and pushes no stack items, and it causes an exceptional abort when executed. this means initcode or already deployed code starting with this instruction will continue to abort execution. unless otherwised specified, all integers are encoded in big-endian byte order. code validation we introduce code validation for new contract creation. to achieve this, we define a format called evm object format (eof), containing a version indicator, and a ruleset of validity tied to a given version. at block.number == hf_block new contract creation is modified: if initcode or code starts with the magic, it is considered to be eof formatted and will undergo validation specified in the following sections, else if code starts with 0xef, creation continues to result in an exceptional abort (the rule introduced in eip-3541), otherwise code is considered legacy code and the following rules do not apply to it. for a create transaction, if initcode or code is invalid, the contract creation results in an exceptional abort. such a transaction is valid and may be included in a block. therefore, the transaction sender’s nonce is increased. for the create and create2 instructions, if initcode or code is invalid, instructions’ execution ends with the result 0 pushed on stack. the initcode validation happens just before its execution and validation failure is observable as if execution results in an exceptional abort. i.e. in case initcode or returned code is invalid the caller’s nonce remains increased and all creation gas is deducted. container specification eof container is a binary format with the capability of providing the eof version number and a list of eof sections. the container starts with the eof header: description length value magic 2-bytes 0xef00 version 1-byte 0x01–0xff eof version number the eof header is followed by at least one section header. each section header contains two fields, section_kind and either section_size or section_size_list, depending on the kind. section_size_list is a list of size values when multiple sections of this kind are allowed. description length value section_kind 1-byte 0x01–0xff uint8 section_size 2-bytes 0x0000–0xffff uint16 section_size_list dynamic n/a uint16, uint16+ the list of section headers is terminated with the section headers terminator byte 0x00. the body content follows immediately after. container validation rules version must not be 0.[^1](#eof-version-range-start-with-1) section_kind must not be 0. the value 0 is reserved for section headers terminator byte. there must be at least one section (and therefore section header). section content size must be equal to size declared in its header. stray bytes outside of sections must not be present. this includes trailing bytes after the last section. eof version 1 eof version 1 is made up of 5 eips, including this one: eip-3540, eip-3670, eip-4200, eip-4750, and eip-5450. some values in this specification are only discussed briefly. to understand the full scope of eof, it is necessary to review each eip in-depth. container the eof version 1 container consists of a header and body. container := header, body header := magic, version, kind_type, type_size, kind_code, num_code_sections, code_size+, kind_data, data_size, terminator body := type_section, code_section+, data_section type_section := (inputs, outputs, max_stack_height)+ note: , is a concatenation operator and + should be interpreted as “one or more” of the preceding item header name length value description magic 2 bytes 0xef00 eof prefix version 1 byte 0x01 eof version kind_type 1 byte 0x01 kind marker for eip-4750 type section header type_size 2 bytes 0x0004-0xfffc uint16 denoting the length of the type section content, 4 bytes per code segment kind_code 1 byte 0x02 kind marker for code size section num_code_sections 2 bytes 0x0001-0x0400 uint16 denoting the number of the code sections code_size 2 bytes 0x0001-0xffff uint16 denoting the length of the code section content kind_data 1 byte 0x03 kind marker for data size section data_size 2 bytes 0x0000-0xffff uint16 integer denoting the length of the data section content terminator 1 byte 0x00 marks the end of the header body name length value description type_section variable n/a stores eip-4750 and eip-5450 code section metadata inputs 1 byte 0x00-0x7f number of stack elements the code section consumes outputs 1 byte 0x00-0x7f number of stack elements the code section returns max_stack_height 2 bytes 0x0000-0x3ff max height of operand stack during execution code_section variable n/a arbitrary bytecode data_section variable n/a arbitrary sequence of bytes see eip-4750 for more information on the type section content. eof version 1 validation rules in addition to general validation rules above, eof version 1 bytecode conforms to the rules specified below: exactly one type section header must be present immediately following the eof version. each code section must have a specified type signature in the type body. exactly one code section header must be present immediately following the type section. a maximum of 1024 individual code sections are allowed. exactly one data section header must be present immediately following the code section. any version other than 0x01 is invalid. (remark: contract creation code should set the section size of the data section so that the constructor arguments fit it.) changes to execution semantics for clarity, the container refers to the complete account code, while code refers to the contents of the code section only. execution starts at the first byte of the first code section, and pc is set to 0. execution stops if pc goes outside the code section bounds. pc returns the current position within the code. codecopy/codesize/extcodecopy/extcodesize/extcodehash keeps operating on the entire container. the input to create/create2 is still the entire container. the size limit for deployed code as specified in eip-170 and for initcode as specified in eip-3860 is applied to the entire container size, not to the code size. this also means if initcode validation fails, it is still charged the eip-3860 initcode_cost. when an eof1 contract performs a delegatecall the target must be eof1. if it is not eof1, the delegatecall execution finishes as a failed call by pushing 0 to the stack. only initial gas cost of delegatecall is consumed (similarly to the call depth check) and the target address still becomes warm. (remark: due to eip-4750, jump and jumpi are disabled and therefore are not discussed in relation to eof.) changes to contract creation semantics for clarity, the eof prefix together with a version number n is denoted as the eofn prefix, e.g. eof1 prefix. if initcode’s container has eof1 prefix it must be valid eof1 code. if code’s container has eof1 prefix it must be valid eof1 code. if initcode’s container is valid eof1 code the resulting code’s container must be valid eof1 code (i.e. it must not be empty and must not produce legacy code). if create or create2 instruction is executed in an eof1 code the instruction’s initcode must be valid eof1 code (i.e. eof1 contracts must not produce legacy code). see code validation above for specification of behaviour in case one of these conditions is not satisfied. rationale evm and/or account versioning has been discussed numerous times over the past years. this proposal aims to learn from them. see “ethereum account versioning” on the fellowship of ethereum magicians forum for a good starting point. execution vs. creation time validation this specification introduces creation time validation, which means: all created contracts with eofn prefix are valid according to version n rules. this is very strong and useful property. the client can trust that the deployed code is well-formed. in the future, this allows to serialize jumpdest map in the eof container and eliminate the need of implicit jumpdest analysis required before execution. or to completely remove the need for jumpdest instructions. this helps with deprecating evm instructions and/or features. the biggest disadvantage is that deploy-time validation of eof code must be enabled in two hard-forks. however, the first step (eip-3541) is already deployed in london. the alternative is to have execution time validation for eof. this is performed every single time a contract is executed, however clients may be able to cache validation results. this alternative approach has the following properties: because the validation is consensus-level execution step, it means the execution always requires the entire code. this makes code merkleization impractical. can be enabled via a single hard-fork. better backwards compatibility: data contracts starting with the 0xef byte or the eof prefix can be deployed. this is a dubious benefit, however. contract creation restrictions the changes to contact creation semantics section defines minimal set of restrictions related to the contract creation: if initcode or code has the eof1 container prefix it must be validated. this adds two validation steps in the contract creation, any of it failing will result in contract creation failure. moreover, it is not allowed to create legacy contracts from eof1 ones. and the eof version of initcode must match the eof version of the produced code. the rule can be generalized in the future: eofn contract must only create eofm contracts, where m ≥ n. this guarantees that a cluster of eof contracts will never spawn new legacy contracts. furthermore, some exotic contract creation combinations are eliminated (e.g. eof1 contract creating new eof1 contract with legacy initcode). finally, create transaction must be allowed to contain legacy initcode and deploy legacy code because otherwise there is no transition period allowing upgrading transaction signing tools. deprecating such transactions may be considered in the future. the magic the first byte 0xef was chosen because it is reserved for this purpose by eip-3541. the second byte 0x00 was chosen to avoid clashes with three contracts which were deployed on mainnet: 0xca7bf67ab492b49806e24b6e2e4ec105183caa01: eff09f918bf09f9fa9 0x897da0f23ccc5e939ec7a53032c5e80fd1a947ec: ef 0x6e51d4d9be52b623a3d3a2fa8d3c5e3e01175cd0: ef no contracts starting with 0xef bytes exist on public testnets: goerli, ropsten, rinkeby, kovan and sepolia at their london fork block. eof version range start with 1 the version number 0 will never be used in eof, so we can call legacy code eof0. also, implementations may use apis where 0 version number denotes legacy code. section structure we have considered different questions for the sections: streaming headers (i.e. section_header, section_data, section_header, section_data, ...) are used in some other formats (such as webassembly). they are handy for formats which are subject to editing (adding/removing sections). that is not a useful feature for evm. one minor benefit applicable to our case is that they do not require a specific “header terminator”. on the other hand they seem to play worse with code chunking / merkleization, as it is better to have all section headers in a single chunk. whether to have a header terminator or to encode number_of_sections or total_size_of_headers. both raise the question of how large of a value these fields should be able to hold. a terminator byte seems to avoid the problem of choosing a size which is too small without any perceptible downside, so it is the path taken. whether to encode section_size as a fixed 16-bit value or some kind of variable length field (e.g. leb128). we have opted for fixed size, because it simplifies client implementations, and 16-bit seems enough, because of the currently exposed code size limit of 24576 bytes (see eip-170 and eip-3860). should this be limiting in the future, a new eof version could change the format. besides simplifying client implementations, not using leb128 also greatly simplifies on-chain parsing. data-only contracts the eof prevents deploying contracts with arbitrary bytes (data-only contracts: their purpose is to store data not execution). eof1 requires presence of a code section therefore the minimal overhead eof data contract consist of a data section and one code section with single instruction. we recommend to use invalid instruction in this case. in total there are 20 additional bytes required. ef0001 010004 020001 0001 03 00 00000000 fe it is possible in the future that this data will be accessible with data-specific opcodes, such as datacopy or extdatacopy. until then, callers will need to determine the data offset manually. pc starts with 0 at the code section the value for pc is specified to start at 0 and to be within the active code section. we considered keeping pc to operate on the whole container and be consistent with codecopy/extcodecopy but in the end decided otherwise. this also feels more natural and easier to implement in evm: the new eof evm should only care about traversing code and accessing other parts of the container only on special occasions (e.g. in codecopy instruction). eof1 contracts can only delegatecall eof1 contracts currently contracts can selfdestruct in three different ways (directly through selfdestruct, indirectly through callcode and indirectly through delegatecall). eip-3670 disables the first two possibilities, however the third possibility remains. allowing eof1 contracts to only delegatecall other eof1 contracts allows the following strong statement: eof1 contract can never be destructed. attacks based on selfdestruct completely disappear for eof1 contracts. these include destructed library contracts (e.g. parity multisig). backwards compatibility this is a breaking change given that any code starting with 0xef was not deployable before (and resulted in exceptional abort if executed), but now some subset of such codes can be deployed and executed successfully. the choice of magic guarantees that none of the contracts existing on the chain are affected by the new rules. test cases contract creation all cases should be checked for creation transaction, create and create2. legacy init code returns legacy code returns valid eof1 code returns invalid eof1 code, contract creation fails returns 0xef not followed by eof1 code, contract creation fails valid eof1 init code returns legacy code, contract creation fails returns valid eof1 code returns invalid eof1 code, contract creation fails returns 0xef not followed by eof1 code, contract creation fails invalid eof1 init code contract execution eof code containing pc opcode offset inside code section is returned eof code containing codecopy/codesize works as in legacy code codesize returns the size of entire container codecopy can copy from code section codecopy can copy from data section codecopy can copy from the eof header codecopy can copy entire container extcodecopy/extcodesize/extcodehash with the eof target contract works as with legacy target contract extcodesize returns the size of entire target container extcodehash returns the hash of entire target container extcodecopy can copy from target’s code section extcodecopy can copy from target’s data section extcodecopy can copy from target’s eof header extcodecopy can copy entire target container results don’t differ when executed inside legacy or eof contract eof1 delegatecall delegatecall to eof1 code succeeds delegatecall to eof0 code fails delegatecall to empty container fails security considerations with the anticipated eof extensions, the validation is expected to have linear computational and space complexity. we think that the validation cost is sufficiently covered by: eip-3860 for initcode, high per-byte cost of deploying code. copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), paweł bylica (@chfast), andrei maiboroda (@gumb0), matt garnett (@lightclient), "eip-3540: eof evm object format v1 [draft]," ethereum improvement proposals, no. 3540, march 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3540. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1930: calls with strict gas semantic. revert if not enough gas available. ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1930: calls with strict gas semantic. revert if not enough gas available. authors ronan sandford (@wighawag) created 2019-04-10 discussion link https://github.com/ethereum/eips/issues/1930 table of contents simple summary abstract specification rationale backwards compatibility test cases implementation references copyright simple summary add the ability for smart contract to execute calls with a specific amount of gas. if this is not possible the execution should revert. abstract the current call, delegate_call, static_call opcode do not enforce the gas being sent, they simply consider the gas value as a maximum. this pose serious problem for applications that require the call to be executed with a precise amount of gas. this is for example the case for meta-transaction where the contract needs to ensure the call is executed exactly as the signing user intended. but this is also the case for common use cases, like checking “on-chain” if a smart contract support a specific interface (via eip-165 for example). the solution presented here is to add new call semantic that enforce the amount of gas specified : the call either proceed with the exact amount of gas or do not get executed and the current call revert. specification there are 2 possibilities a) one is to add opcode variant that have a stricter gas semantic b) the other is to consider a specific gas value range (one that have never been used before) to have strict gas semantic, while leaving other values as before here are the details description option a) add a new variant of the call opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert add a new variant of the delegate_call opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert add a new variant of the static_call opcode where the gas specified is enforced so that if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert rational for a) this solution has the merit to avoid any possibility of old contract be affected by the change. on the other hand it introduce 3 new opcodes. with eip-1702, we could render the old opcode obsolete though. option b) for all opcode that allow to pass gas to another contract, do the following: if the most significant bit is one, consider the 31 less significant bit as the amount of gas to be given to the receiving contract in the strict sense. so like a) if the gas left at the point of call is not enough to give the specified gas to the destination, the current call revert. if the 2nd most significant bit is zero, consider the whole value to behave like before, that is, it act as a maximum value, and even if not enough gas is present, the gas that can be given is given to the receiving contract rational for b) this solution relies on the fact that no contract would have given any value bigger or equal to 0x8000000000000000000000000000000000000000000000000000000000000000 note that solidity for example do not use value like 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff as it is more expensive than passing the gasleft. its main benefit though is that it does not require extra opcodes. strict gas semantic to be precise, regarding the strict gas semantic, based on eip-150, the current call must revert unless g >= i x 64/63 where g is gas left at the point of call (after deducing the cost of the call itself) and i is the gas specified. so instead of availablegas = availablegas base gas := availablegas availablegas/64 ... if !callcost.isuint64() || gas < callcost.uint64() { return gas, nil } see https://github.com/ethereum/go-ethereum/blob/7504dbd6eb3f62371f86b06b03ffd665690951f2/core/vm/gas.go#l41-l48 we would have availablegas = availablegas base gas := availablegas availablegas/64 if !callcost.isuint64() || gas < callcost.uint64() { return 0, errnotenoughgas } rationale currently the gas specified as part of these opcodes is simply a maximum value. and due to the behavior of eip-150 it is possible for an external call to be given less gas than intended (less than the gas specified as part of the call) while the rest of the current call is given enough to continue and succeed. indeed since with eip-150, the external call is given at max g math.floor(g/64) where g is the gasleft() at the point of the call, the rest of the current call is given math.floor(g/64) which can be plenty enough for the transaction to succeed. for example, when g = 6,400,000 the rest of the transaction will be given 100,000 gas plenty enough in many case to succeed. this is an issue for contracts that require external call to only fails if they would fails with enough gas. this requirement is present in smart contract wallet and meta transaction in general, where the one executing the transaction is not the signer of the execution data. because in such case, the contract needs to ensure the call is executed exactly as the signing user intended. but this is also true for simple use case, like checking if a contract implement an interface via eip-165. indeed as specified by such eip, the supporstinterface method is bounded to use 30,000 gas so that it is theoretically possible to ensure that the throw is not a result of a lack of gas. unfortunately due to how the different call opcodes behave contracts can’t simply rely on the gas value specified. they have to ensure by other means that there is enough gas for the call. indeed, if the caller do not ensure that 30,000 gas or more is provided to the callee, the callee might throw because of a lack of gas (and not because it does not support the interface), and the parent call will be given up to 476 gas to continue. this would result in the caller interpreting wrongly that the callee is not implementing the interface in question. while such requirement can be enforced by checking the gas left according to eip-150 and the precise gas required before the call (see solution presented in that bug report or after the call (see the native meta transaction implementation here, it would be much better if the evm allowed us to strictly specify how much gas is to be given to the call so contract implementations do not need to follow eip-150 behavior and the current gas pricing so closely. this would also allow the behaviour of eip-150 to be changed without having to affect contract that require this strict gas behaviour. as mentioned, such strict gas behaviour is important for smart contract wallet and meta transaction in general. the issue is actually already a problem in the wild as can be seen in the case of gnosis safe which did not consider the behavior of eip-150 and thus fails to check the gas properly, requiring the safe owners to add otherwise unnecessary extra gas to their signed message to avoid the possibility of losing funds. see https://github.com/gnosis/safe-contracts/issues/100 as for eip-165, the issue already exists in the example implementation presented in the eip. please see the details of the issue here the same issue exists also on openzeppelin implementation, a library used by many. it does not for perform any check on gas before calling supportsinterface with 30,000 gas (see here and is thus vulnerable to the issue mentioned. while such issue can be prevented today by checking the gas with eip-150 in mind, a solution at the opcode level is more elegant. indeed, the two possible ways to currently enforce that the correct amount of gas is sent are as follow : 1) check done before the call uint256 gasavailable = gasleft() e; require(gasavailable gasavailable / 64 >= `txgas`, "not enough gas provided") to.call.gas(txgas)(data); // call where e is the gas required for the operation between the call to gasleft() and the actual call plus the gas cost of the call itself. while it is possible to simply over estimate e to prevent call to be executed if not enough gas is provided to the current call it would be better to have the evm do the precise work itself. as gas pricing continue to evolve, this is important to have a mechanism to ensure a specific amount of gas is passed to the call so such mechanism can be used without having to relies on a specific gas pricing. 2) check done after the call: to.call.gas(txgas)(data); // call require(gasleft() > txgas / 63, "not enough gas left"); this solution does not require to compute a e value and thus do not relies on a specific gas pricing (except for the behaviour of eip-150) since if the call is given not enough gas and fails for that reason, the condition above will always fail, ensuring the current call will revert. but this check still pass if the gas given was less and the external call reverted or succeeded early (so that the gas left after the call > txgas / 63). this can be an issue if the code executed as part of the call is reverting as a result of a check against the gas provided. like a meta transaction in a meta transaction. similarly to the the previous solution, an evm mechanism would be much better. backwards compatibility for specification a) : backwards compatible as it introduce new opcodes. for specification b) : backwards compatible as it use value range outside of what is used by existing contract (to be verified) test cases implementation none fully implemented yet. but see specifications for an example in geth. references eip-150, ./eip-150.md copyright copyright and related rights waived via cc0. citation please cite this document as: ronan sandford (@wighawag), "eip-1930: calls with strict gas semantic. revert if not enough gas available. [draft]," ethereum improvement proposals, no. 1930, april 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1930. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5409: eip-1155 non-fungible token extension ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5409: eip-1155 non-fungible token extension allow eip-1155 to represent non-fungible tokens (tokens who have a unique owner) authors ronan sandford (@wighawag) created 2022-07-23 discussion link https://ethereum-magicians.org/t/eip-5409-non-fungible-token-extension-for-eip-1155/10240 requires eip-165, eip-721, eip-1155 table of contents abstract motivation specification contract interface rationale backwards compatibility security considerations copyright abstract this standard is an extension of eip-1155. it proposes an additional function, ownerof, which allows eip-1155 tokens to support non-fungibility (unique owners). by implementing this extra function, eip-1155 tokens can benefit from eip-721’s core functionality without implementing the (less efficient) eip-721 specification in the same contract. motivation currently, eip-1155 does not allow an external caller to detect whether a token is truly unique (can have only one owner) or fungible. this is because eip-1155 do not expose a mechanism to detect whether a token will have its supply remain to be “1”. furthermore, it does not let an external caller retrieve the owner directly on-chain. the eip-1155 specification does mention the use of split id to represent non-fungible tokens, but this requires a pre-established convention that is not part of the standard, and is not as simple as eip-721’s ownerof. the ability to get the owner of a token enables novel use-cases, including the ability for the owner to associate data with it. specification the keywords “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may” and “optional” in this document are to be interpreted as described in rfc 2119. contract interface interface ierc1155ownerof { /// @notice find the owner of an nft /// @dev the zero address indicates that there is no owner: either the token does not exist or it is not an nft (supply potentially bigger than 1) /// @param tokenid the identifier for an nft /// @return the address of the owner of the nft function ownerof(uint256 tokenid) external view returns (address); } the ownerof(uint256 tokenid) function may be implemented as pure or view. the supportsinterface method must return true when called with 0x6352211e. rationale ownerof does not throw when a token does not exist (or does not have an owner). this simplifies the handling of such a case. since it would be a security risk to assume all eip-721 implementation would throw, it should not break compatibility with contract handling eip-721 when dealing with this eip-1155 extension. backwards compatibility this eip is fully backward compatible with eip-1155. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: ronan sandford (@wighawag), "erc-5409: eip-1155 non-fungible token extension [draft]," ethereum improvement proposals, no. 5409, july 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5409. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-165: standard interface detection ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-165: standard interface detection authors christian reitwießner , nick johnson , fabian vogelsteller , jordi baylina , konrad feldmeier , william entriken created 2018-01-23 requires eip-214 table of contents simple summary abstract motivation specification how interfaces are identified how a contract will publish the interfaces it implements how to detect if a contract implements erc-165 how to detect if a contract implements any given interface rationale backwards compatibility test cases implementation version history copyright simple summary creates a standard method to publish and detect what interfaces a smart contract implements. abstract herein, we standardize the following: how interfaces are identified how a contract will publish the interfaces it implements how to detect if a contract implements erc-165 how to detect if a contract implements any given interface motivation for some “standard interfaces” like the erc-20 token interface, it is sometimes useful to query whether a contract supports the interface and if yes, which version of the interface, in order to adapt the way in which the contract is to be interacted with. specifically for erc-20, a version identifier has already been proposed. this proposal standardizes the concept of interfaces and standardizes the identification (naming) of interfaces. specification how interfaces are identified for this standard, an interface is a set of function selectors as defined by the ethereum abi. this a subset of solidity’s concept of interfaces and the interface keyword definition which also defines return types, mutability and events. we define the interface identifier as the xor of all function selectors in the interface. this code example shows how to calculate an interface identifier: pragma solidity ^0.4.20; interface solidity101 { function hello() external pure; function world(int) external pure; } contract selector { function calculateselector() public pure returns (bytes4) { solidity101 i; return i.hello.selector ^ i.world.selector; } } note: interfaces do not permit optional functions, therefore, the interface identity will not include them. how a contract will publish the interfaces it implements a contract that is compliant with erc-165 shall implement the following interface (referred as erc165.sol): pragma solidity ^0.4.20; interface erc165 { /// @notice query if a contract implements an interface /// @param interfaceid the interface identifier, as specified in erc-165 /// @dev interface identification is specified in erc-165. this function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceid` and /// `interfaceid` is not 0xffffffff, `false` otherwise function supportsinterface(bytes4 interfaceid) external view returns (bool); } the interface identifier for this interface is 0x01ffc9a7. you can calculate this by running bytes4(keccak256('supportsinterface(bytes4)')); or using the selector contract above. therefore the implementing contract will have a supportsinterface function that returns: true when interfaceid is 0x01ffc9a7 (eip165 interface) false when interfaceid is 0xffffffff true for any other interfaceid this contract implements false for any other interfaceid this function must return a bool and use at most 30,000 gas. implementation note, there are several logical ways to implement this function. please see the example implementations and the discussion on gas usage. how to detect if a contract implements erc-165 the source contract makes a staticcall to the destination address with input data: 0x01ffc9a701ffc9a700000000000000000000000000000000000000000000000000000000 and gas 30,000. this corresponds to contract.supportsinterface(0x01ffc9a7). if the call fails or return false, the destination contract does not implement erc-165. if the call returns true, a second call is made with input data 0x01ffc9a7ffffffff00000000000000000000000000000000000000000000000000000000. if the second call fails or returns true, the destination contract does not implement erc-165. otherwise it implements erc-165. how to detect if a contract implements any given interface if you are not sure if the contract implements erc-165, use the above procedure to confirm. if it does not implement erc-165, then you will have to see what methods it uses the old-fashioned way. if it implements erc-165 then just call supportsinterface(interfaceid) to determine if it implements an interface you can use. rationale we tried to keep this specification as simple as possible. this implementation is also compatible with the current solidity version. backwards compatibility the mechanism described above (with 0xffffffff) should work with most of the contracts previous to this standard to determine that they do not implement erc-165. also the ens already implements this eip. test cases following is a contract that detects which interfaces other contracts implement. from @fulldecent and @jbaylina. pragma solidity ^0.4.20; contract erc165query { bytes4 constant invalidid = 0xffffffff; bytes4 constant erc165id = 0x01ffc9a7; function doescontractimplementinterface(address _contract, bytes4 _interfaceid) external view returns (bool) { uint256 success; uint256 result; (success, result) = nothrowcall(_contract, erc165id); if ((success==0)||(result==0)) { return false; } (success, result) = nothrowcall(_contract, invalidid); if ((success==0)||(result!=0)) { return false; } (success, result) = nothrowcall(_contract, _interfaceid); if ((success==1)&&(result==1)) { return true; } return false; } function nothrowcall(address _contract, bytes4 _interfaceid) constant internal returns (uint256 success, uint256 result) { bytes4 erc165id = erc165id; assembly { let x := mload(0x40) // find empty storage location using "free memory pointer" mstore(x, erc165id) // place signature at beginning of empty storage mstore(add(x, 0x04), _interfaceid) // place first argument directly next to signature success := staticcall( 30000, // 30k gas _contract, // to addr x, // inputs are stored at location x 0x24, // inputs are 36 bytes long x, // store output over input (saves space) 0x20) // outputs are 32 bytes long result := mload(x) // load the result } } } implementation this approach uses a view function implementation of supportsinterface. the execution cost is 586 gas for any input. but contract initialization requires storing each interface (sstore is 20,000 gas). the erc165mappingimplementation contract is generic and reusable. pragma solidity ^0.4.20; import "./erc165.sol"; contract erc165mappingimplementation is erc165 { /// @dev you must not set element 0xffffffff to true mapping(bytes4 => bool) internal supportedinterfaces; function erc165mappingimplementation() internal { supportedinterfaces[this.supportsinterface.selector] = true; } function supportsinterface(bytes4 interfaceid) external view returns (bool) { return supportedinterfaces[interfaceid]; } } interface simpson { function is2d() external returns (bool); function skincolor() external returns (string); } contract lisa is erc165mappingimplementation, simpson { function lisa() public { supportedinterfaces[this.is2d.selector ^ this.skincolor.selector] = true; } function is2d() external returns (bool){} function skincolor() external returns (string){} } following is a pure function implementation of supportsinterface. the worst-case execution cost is 236 gas, but increases linearly with a higher number of supported interfaces. pragma solidity ^0.4.20; import "./erc165.sol"; interface simpson { function is2d() external returns (bool); function skincolor() external returns (string); } contract homer is erc165, simpson { function supportsinterface(bytes4 interfaceid) external view returns (bool) { return interfaceid == this.supportsinterface.selector || // erc165 interfaceid == this.is2d.selector ^ this.skincolor.selector; // simpson } function is2d() external returns (bool){} function skincolor() external returns (string){} } with three or more supported interfaces (including erc165 itself as a required supported interface), the mapping approach (in every case) costs less gas than the pure approach (at worst case). version history pr 1640, finalized 2019-01-23 – this corrects the nothrowcall test case to use 36 bytes rather than the previous 32 bytes. the previous code was an error that still silently worked in solidity 0.4.x but which was broken by new behavior introduced in solidity 0.5.0. this change was discussed at #1640. eip 165, finalized 2018-04-20 – original published version. copyright copyright and related rights waived via cc0. citation please cite this document as: christian reitwießner , nick johnson , fabian vogelsteller , jordi baylina , konrad feldmeier , william entriken , "erc-165: standard interface detection," ethereum improvement proposals, no. 165, january 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-165. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. ether sale: a statistical overview | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search ether sale: a statistical overview posted by vitalik buterin on august 8, 2014 organizational the first two weeks of the ether sale are over, and we have to date received over 25000 btc from selling over 50 million eth. this marks the largest cryptographic token sale to date, and with the two endowments places eth as being the token with the 8th highest total value, even beating out the beloved dogecoin at 17.3musdvs17.3m usd vs 17.3musdvs15.5m. a total of 6670 transactions have been made, with values ranging from the minimum 0.01 btc to a high of 500 btc, and purchases continue to come in every hour. additionally, the ether sale marks the largest use of multisig to date; because of our sale, the percentage of all btc stored in multisig has shot up from 0.23% to 0.41% over the last two weeks alone in other words, the 3-of-4 private keys split between our various sites control 45% of all btc stored in multisig addresses in existence. the purpose of this post will be to provide an overview of some statistics from the sale so far. data was taken yesterday, when we had 24000 btc, and assumes that all purchases were for 2000 eth / btc (an assumption that is not strictly true, but the error term is sufficiently tiny that it can safely be discounted). first we have this spreadsheet, which shows the ether purchases over time. the individual spikes are per-block; the chart shows that the distribution is heavily divided into two clusters, with one cluster closer to the start of the sale and the other close to the end of the full-discount period. purchases drop off sharply once the new price level of 1970 eth/btc (now 1910 eth/btc) kicked in. theoretically, purchasing near the end of the full-discount period is the more optimal strategy from a naive game-theoretic model; if you purchase near the end of the full-discount period then you get the same price as people who purchased at the start, but also gain the benefit of having more information namely, a better idea of the exact percentage of all eth that you are going to get. thus, the fact that the majority of purchases occurred at the end shows that ether purchasers are generally a rather sophisticated audience which i suppose you should be if you managed to be convinced to trade your hard-earned btc for some cryptographic tokens backed by a concept of "generalized consensus computing". of course, it is important to note that there are reasons to buy at the start too. some people are participating in the sale out of a desire to support the project, and some large purchasers may have perhaps had the priming effect in mind, where putting larger sums of money (eg. bills) into a tipping jar at the very beginning increases the total amount received because it creates the impression that the recipient is significant and merits more and larger contributions. at this point, we can expect to see a declining flow that will stabilize over the next few days, and then a smaller final spike on day 42. the chart below shows the cumulative ether sold up until this point: https://docs.google.com/a/ethereum.org/spreadsheets/d/1h5w9yvp1eronp8n9uffvccz51q5dxzjaovlicaat46g/gviz/chartiframe?oid=831527247 the other interesting thing to analyze is the distribution of purchases. this spreadsheet contains a list of purchases arranged by purchase size. the largest single purchase was 500 btc (1 million ether), followed by one at 466 btc (933,580 eth) and 330 btc (660,360 eth). we have not received any requests at largepurchases@ethereum.org. if we arrange purchases by size, we get the following two graphs, one for the quantity of purchases and one for the amount of eth purchased, by purchase size: https://docs.google.com/a/ethereum.org/spreadsheets/d/1gs9pzsdmx9lk0xgskedr_aoi02riq3mpryventvum68/gviz/chartiframe?oid=168457404 https://docs.google.com/a/ethereum.org/spreadsheets/d/1gs9pzsdmx9lk0xgskedr_aoi02riq3mpryventvum68/gviz/chartiframe?oid=846945325 note that this only applies to purchases. there is also another slice of ether which will soon be distributed, which is the endowment. the portions in which the endowment is planned to be distributed are on the spreadsheet; the largest is equal to 0.922% of all ether purchased (ie. 0.369% of the total supply after five years) and the smallest is 0.004%, with 81 people total receiving a share. if you are one of the recipients, you will be contacted shortly; if you are not then there is still a second slice whose distribution has not been decided. distribution and gini indices as a final set of interesting statistics, we have calculated three gini indices: gini index of ether purchasers: 0.832207 gini index of endowment: 0.599638 gini index of entire set: 0.836251 a gini index is a common measure of inequality; the way the gini index is calculated is by drawing a chart, with both axes going from 0% to 100%, and drawing a line where the y coordinate at a particular x coordinate is calculated as the portion of all income (or wealth) which is owned by the bottom x percent of the population. the area between this curve and a diagonal line, as a portion of the area of the entire triangle under the diagonal line, is the gini index: in an ideal society of perfect equality, the coefficient would be zero; the bottom x% of the population would obviously have x% of the wealth, just like any other x% of the population, so the cumulative wealth distribution graph would be exactly the diagonal line and thus the area between the graph and the diagonal line would be zero. in the opposite scenario, an ultimate dictatorship where one person controls everything, the bottom x% would have exactly nothing all the way up until the last person, who would have everything; hence, the area between that curve and the diagonal line would be equal to the entire area under the diagonal line, and the coefficient would be exactly one. most real-world scenarios are in between the two. note that gini coefficients of wealth and gini coefficients of income are different things; one measures how much people have and one measures the rate at which people receive. because savings are superlinear in income, coefficients of wealth tend to be higher; the gini coefficient of wealth in the us, for example, is 0.801, and the coefficient of the world is 0.804. given that gini coefficients in the real world measure inequality of access to resources, and gini coefficients in cryptocurrency distribution arise from both inequality of resources and inequality of interest (some people care about ethereum slightly, some care about it a whole lot), 0.836 is a pretty decent result as a point of comparison, the gini coefficient of bitcoin has been measured at 0.877. the top 100 current eth holders are responsible for 45.7% of all eth, a lower percentage than the top 100 holders of the mainstream altcoins, where that statistic tends to be between 55% and 70%. of course, these last two comparisons are misleading the ethereum ecosystem has not even started to actually run, and services like exchanges which centralize control over currency units into a few wallets without centralizing legal ownership do end up artificially inflating both the gini index and the top-100 score of cryptocurrency networks that are actually live. once ethereum launches, the gini index may well prove to be impossible to accurately estimate, since large quantities of ether will be stored inside decentralized applications running arbitrary, turing-complete, and thus in many cases mathematically inscrutable, rulesets for how the ether can be withdrawn. the sale still has 28 days left to go; although we are not expecting much out of this remaining period, anything is possible. with organizational issues being wrapped up, the organization is getting ready to substantially scale up development, putting us on the fast track to finally completing the ethereum code and launching the genesis block; eta winter 2014-2015. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-5606: multiverse nfts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-5606: multiverse nfts a universal representation of multiple related nfts as a single digital asset across various platforms authors gaurang torvekar (@gaurangtorvekar), khemraj adhawade (@akhemraj), nikhil asrani (@nikhilasrani) created 2022-09-06 requires eip-721, eip-1155 table of contents abstract motivation specification rationale backwards compatibility reference implementation security considerations copyright abstract this specification defines a minimal interface to create a multiverse nft standard for digital assets such as wearables and in-game items that, in turn, index the delegate nfts on each platform where this asset exists. these platforms could be metaverses, play-to-earn games or nft marketplaces. this proposal depends on and extends erc-721 and erc-1155. the standard also allows for the ‘bundling’ and ‘unbundling’ of these delegate nfts within the multiverse nft so holders can trade them individually or as a bundle. motivation several metaverses and blockchain games (“platforms”) exist that use nft standards such as erc-721 and erc-1155 for creating in-universe assets like avatar wearables, in-game items including weapons, shields, potions and much more. the biggest shortcoming while using these standards is that there is no interoperability between these platforms. as a publisher, you must publish the same digital asset (for example, a shirt) on various platforms as separate erc-721 or erc-1155 tokens. moreover, there is no relationship between these, although they represent the same digital asset in reality. hence, it is very difficult to prove the scarcity of these items on-chain. since their inception, nfts were meant to be interoperable and prove the scarcity of digital assets. although nfts can arguably prove the scarcity of items, the interoperability aspect hasn’t been addressed yet. creating a multiverse nft standard that allows for indexing and ownership of a digital asset across various platforms would be the first step towards interoperability and true ownership across platforms. in the web3 ecosystem, nfts have evolved to represent multiple types of unique and non-fungible assets. one type of asset includes a set of nfts related to one another. for instance, if a brand releases a new sneaker across various metaverses, it would be minted as a separate nft on each platform. however, it is, in reality, the same sneaker. there is a need to represent the relationship and transferability of these types of nfts as metaverses and blockchain games gain more mainstream adoption. the ecosystem needs a better framework to address this issue rather than relying on the application level. this framework should define the relationship between these assets and the nature of their association. there is more value in the combined recognition, use and transferability of these individual nfts as a bundle rather than their selves. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. a multiverse nft contract represents a digital asset across multiple platforms. this contract can own one or more delegate nft tokens of the digital asset on the various platforms through bundling or unbundling. /** * @dev interface of the multiverse nft standard as defined in the eip. */ interface imultiversenft { /** * @dev struct to store delegate token details * */ struct delegatedata { address contractaddress; uint256 tokenid; uint256 quantity; } /** * @dev emitted when one or more new delegate nfts are added to a multiverse nft */ event bundled(uint256 multiversetokenid, delegatedata[] delegatedata, address owneraddress); /** * @dev emitted when one or more delegate nfts are removed from a multiverse nft */ event unbundled(uint256 multiversetokenid, delegatedata[] delegatedata); /** * @dev accepts the tokenid of the multiverse nft and returns an array of delegate token data */ function delegatetokens(uint256 multiversetokenid) external view returns (delegatedata[] memory); /** * @dev removes one or more delegate nfts from a multiverse nft * this function accepts the delegate nft details and transfers those nfts out of the multiverse nft contract to the owner's wallet */ function unbundle(delegatedata[] memory delegatedata, uint256 multiversetokenid) external; /** * @dev adds one or more delegate nfts to a multiverse nft * this function accepts the delegate nft details and transfers those nfts to the multiverse nft contract * need to ensure that approval is given to this multiverse nft contract for the delegate nfts so that they can be transferred programmatically */ function bundle(delegatedata[] memory delegatedata, uint256 multiversetokenid) external; /** * @dev initialises a new bundle, mints a multiverse nft and assigns it to msg.sender * returns the token id of a new multiverse nft * note when a new multiverse nft is initialised, it is empty; it does not contain any delegate nfts */ function initbundle(delegatedata[] memory delegatedata) external; } any dapp implementing this standard would initialise a bundle by calling the function initbundle. this mints a new multiverse nft and assigns it to msg.sender. while creating a bundle, the delegate token contract addresses and the token ids are set during the initialisation and cannot be changed after that. this avoids unintended edge cases where non-related nfts could be bundled together by mistake. once a bundle is initialised, the delegate nft tokens can then be transferred to this multiverse nft contract by calling the function bundle and passing the token id of the multiverse nft. it is essential for a dapp to get the delegate nfts ‘approved’ from the owner to this multiverse nft contract before calling the bundle function. after that, the multiverse nft owns one or more versions of this digital asset across the various platforms. if the owner of the multiverse nft wants to sell or use the individual delegate nfts across any of the platforms, they can do so by calling the function unbundle. this function transfers the particular delegate nft token(s) to msg.sender (only if msg.sender is the owner of the multiverse nft). rationale the delegatedata struct contains information about the delegate nft tokens on each platform. it contains variables such as contractaddress, tokenid, quantity to differentiate the nfts. these nfts could be following either the erc-721 standard or the erc-1155 standard. the bundle and unbundle functions accept an array of delegatedata struct because of the need to cater to partial bundling and unbundling. for instance, a user could initialise a bundle with three delegate nfts, but they should be able to bundle and unbundle less than three at any time. they can never bundle or unbundle more than three. they also need the individual token ids of the delegate nfts to bundle and unbundle selectively. backwards compatibility this standard is fully compatible with erc-721 and erc-1155. third-party applications that don’t support this eip will still be able to use the original nft standards without any problems. reference implementation multiversenft.sol security considerations the bundle function involves calling an external contract(s). so reentrancy prevention measures should be applied while implementing this function. copyright copyright and related rights waived via cc0. citation please cite this document as: gaurang torvekar (@gaurangtorvekar), khemraj adhawade (@akhemraj), nikhil asrani (@nikhilasrani), "erc-5606: multiverse nfts," ethereum improvement proposals, no. 5606, september 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5606. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-4974: ratings ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-4974: ratings an interface for assigning and managing numerical ratings authors daniel tedesco (@dtedesco1) created 2022-04-02 discussion link https://ethereum-magicians.org/t/8805 requires eip-165 table of contents abstract motivation specification rationale rating assignment choice of int8 rating changes interface detection metadata choices drawbacks backwards compatibility reference implementation security considerations copyright abstract this standard defines a standardized interface for assigning and managing numerical ratings on the ethereum blockchain. this allows ratings to be codified within smart contracts and recognized by other applications, enabling a wide range of new use cases for tokens. motivation traditionally, blockchain applications have focused on buying and selling digital assets. however, the asset-centric model has often been detrimental to community-based blockchain projects, as seen in the pay-to-play dynamics of many evm-based games and daos in 2021. this proposal addresses this issue by allowing ratings to be assigned to contracts and wallets, providing a new composable primitive for blockchain applications. this allows for a diverse array of new use cases, such as: voting weight in a dao: ratings assigned using this standard can be used to determine the voting weight of members in a decentralized autonomous organization (dao). for example, a dao may assign higher ratings to members who have demonstrated a strong track record of contributing to the community, and use these ratings to determine the relative influence of each member in decision-making processes. experience points in a decentralized game ecosystem: ratings can be used to track the progress of players in a decentralized game ecosystem, and to reward them for achieving specific milestones or objectives. for example, a game may use ratings to assign experience points to players, which can be used to unlock new content or abilities within the game. loyalty points for customers of a business: ratings can be used to track the loyalty of customers to a particular business or service, and to reward them for their continued support. for example, a business may use ratings to assign loyalty points to customers, which can be redeemed for special offers or discounts. asset ratings for a decentralized insurance company: ratings can be used to evaluate the risk profile of assets in a decentralized insurance company, and to determine the premiums and coverage offered to policyholders. for example, a decentralized insurance company may use ratings to assess the risk of different types of assets, and to provide lower premiums and higher coverage to assets with lower risk ratings. this standard is influenced by the eip-20 and eip-721 token standards and takes cues from each in its structure, style, and semantics. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. every compliant contract must implement the following interfaces: // spdx-license-identifier: cc0 pragma solidity ^0.8.0; /// @title eip-4974 ratings /// @dev see https://eips.ethereum.org/eips/eip-4974 /// note: the eip-165 identifier for this interface is #######. /// must initialize contracts with an `operator` address that is not `address(0)`. interface ierc4974 /* is erc165 */ { /// @dev emits when operator changes. /// must emit when `operator` changes by any mechanism. /// must only emit by `setoperator`. event newoperator(address indexed _operator); /// @dev emits when operator issues a rating. /// must emit when rating is assigned by any mechanism. /// must only emit by `rate`. event rating(address _rated, int8 _rating); /// @dev emits when operator removes a rating. /// must emit when rating is removed by any mechanism. /// must only emit by `remove`. event removal(address _removed); /// @notice appoint operator authority. /// @dev must throw unless `msg.sender` is `operator`. /// must throw if `operator` address is either already current `operator` /// or is the zero address. /// must emit an `appointment` event. /// @param _operator new operator of the smart contract. function setoperator(address _operator) external; /// @notice rate an address. /// must emit a rating event with each successful call. /// @param _rated address to be rated. /// @param _rating total exp tokens to reallocate. function rate(address _rated, int8 _rating) external; /// @notice remove a rating from an address. /// must emit a remove event with each successful call. /// @param _removed address to be removed. function removerating(address _removed) external; /// @notice return a rated address' rating. /// @dev must register each time `rating` emits. /// should throw for queries about the zero address. /// @param _rated an address for whom to query rating. /// @return int8 the rating assigned. function ratingof(address _rated) external view returns (int8); } interface ierc165 { /// @notice query if a contract implements an interface. /// @dev interface identification is specified in eip-165. this function /// uses less than 30,000 gas. /// @param interfaceid the interface identifier, as specified in eip-165. /// @return bool `true` if the contract implements `interfaceid` and /// `interfaceid` is not 0xffffffff, `false` otherwise. function supportsinterface(bytes4 interfaceid) external view returns (bool); } rationale rating assignment ratings shall be at the sole discretion of the contract operator. this party may be a sports team coach or a multisig dao wallet. we decide not to specify how governance occurs, but only that governance occurs. this allows for a wider range of potential use cases than optimizing for particular decision-making forms. this proposal standardizes a control mechanism to allocate community reputation without encouraging financialization of that recognition. while it does not ensure meritocracy, it opens the door. choice of int8 it’s signed: reviewers should be able to give neutral and negative ratings for the wallets and contracts they interact with. this is especially important for decentralized applications that may be subject to malicious actors. it’s 8bit: the objective here is to keep ratings within some fathomably comparable range. longer term, this could encourage easy aggregation of ratings, versus using larger numbers where users might employ a great variety of scales. rating changes ratings should allow rating updates by contract operators. if bob has contributed greatly to the community, but then is caught stealing from alice, the community may decide this should lower bob’s standing and influence in the community. again, while this does not ensure an ethical standard within the community, it opens the door. relatedly, ratings should allow removal of ratings to rescind a rating if the rater does not have confidence in their ability to rate effectively. interface detection we chose standard interface detection (eip-165) to expose the interfaces that a compliant smart contract supports. metadata choices we have required name and description functions in the metadata extension. name common among major standards for blockchain-based primitives. we included a description function that may be helpful for games or other applications with multiple ratings systems. we remind implementation authors that the empty string is a valid response to name and description if you protest to the usage of this mechanism. we also remind everyone that any smart contract can use the same name and description as your contract. how a client may determine which ratings smart contracts are well-known (canonical) is outside the scope of this standard. drawbacks one potential drawback of using this standard is that ratings are subjective and may not always accurately reflect the true value or quality of a contract or wallet. however, the standard provides mechanisms for updating and removing ratings, allowing for flexibility and evolution over time. users identified in the motivation section have a strong need to identify how a contract or community evaluates another. while some users may be proud of ratings they receive, others may rightly or wrongly receive negative ratings from certain contracts. negative ratings may allow for nefarious activities such as bullying and discrimination. we implore all implementers to be mindful of the consequences of any ratings systems they create with this standard. backwards compatibility we have adopted the name semantics from the eip-20 and eip-721 specifications. reference implementation a reference implementation of this standard can be found in the assets folder. security considerations one potential security concern with this standard is the risk of malicious actors assigning false or misleading ratings to contracts or wallets. this could be used to manipulate voting weights in a dao, or to deceive users into making poor decisions based on inaccurate ratings. to address this concern, the standard includes mechanisms for updating and removing ratings, allowing for corrections to be made in cases of false or misleading ratings. additionally, the use of a single operator address to assign and update ratings provides a single point of control, which can be used to enforce rules and regulations around the assignment of ratings. another potential security concern is the potential for an attacker to gain control of the operator address and use it to manipulate ratings for their own benefit. to mitigate this risk, it is recommended that the operator address be carefully managed and protected, and that multiple parties be involved in its control and oversight. overall, the security of compliant contracts will depend on the careful management and protection of the operator address, as well as the development of clear rules and regulations around the assignment of ratings. copyright copyright and related rights waived via cc0. citation please cite this document as: daniel tedesco (@dtedesco1), "erc-4974: ratings [draft]," ethereum improvement proposals, no. 4974, april 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-4974. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6123: smart derivative contract ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-6123: smart derivative contract a deterministic protocol for frictionless trade processing of financial contracts authors christian fries (@cfries), peter kohl-landgraf (@pekola), alexandros korpis (@kourouta) created 2022-12-13 discussion link https://ethereum-magicians.org/t/eip-6123-smart-derivative-contract-frictionless-processing-of-financial-derivatives/12134 table of contents abstract motivation rethinking financial derivatives concept of a smart derivative contract applications specification methods trade events tradesettlementrequest tradesettlementphase rationale state diagram of trade and process states sequence diagram of trade initiation and settlement life-cycle test cases reference implementation trade data specification (suggestion) security considerations copyright abstract the smart derivative contract (sdc) allows fully automizing and securing a financial product’s e.g. a financial derivative or bond complete trade life cycle. the sdc leverages the advantages of smart contracts to remove many of the frictions associated with the classical derivative life cycle. most notably, the protocol allows the removal of counterpart risk essentially. the sdc can be implemented using a pre-agreed valuation oracle and valuation model, removing ambiguity in the settlement amounts. the sdc provides methods and callbacks to enable fully automated and fully transactional settlements (delivery-versus-payment, payment-vs-payment). token-based settlement can be realized by any contract implementation implementing an erc-20 token. proof of concepts in terms of two legally binding digital interest rate swaps were conducted in 2021 and 2022. motivation rethinking financial derivatives by their very nature, so-called “over-the-counter (otc)” financial contracts are bilateral contractual agreements on exchanging long-dated cash flow schedules. since these contracts change their intrinsic market value due to changing market environments, they are subject to counterparty credit risk when one counterparty is subject to default. the initial white paper describes the concept of a smart derivative contract (sdc) with the central aim to detach bilateral financial transactions from counterparty credit risk and to remove complexities in bilateral post-trade processing by a complete redesign. concept of a smart derivative contract a smart derivative contract is a deterministic settlement protocol with the same economic behaviour as a financial contract e.g. an otc-derivative or a bond. every process state is specified; therefore, the trade and post-trade process is known in advance and is deterministic over the trade’s life cycle. an erc-20 token can be used for frictionless decentralized settlement, see reference implementation. we do provide a separate interface and implementation for a specific “settlement token” derived from erc-20. these features enable two or multiple trade parties to process their financial contracts fully decentralized without relying on a third central intermediary agent. the process logic of sdc can be implemented as a finite state machine on solidity. applications the interface’s life cycle functionality applies to several use cases. collateralized otc derivative in the case of a collateralized otc derivative, an sdc settles the outstanding net present value of the underlying financial contract on a frequent (e.g. daily) basis. with each settlement cycle, the net present value of the underlying contract is exchanged, and the value of the contract is reset to zero. pre-agreed margin buffers are locked at the beginning of each settlement cycle so that settlement will be guaranteed up to a certain amount. if a counterparty fails to obey contract rules, e.g. not providing sufficient pre-funding, sdc will terminate automatically with the guaranteed transfer of a termination fee by the causing party. we provide a reference implementation for this case. defaultable otc derivative a defaultable otc derivative has no collateral process in place. in that case, a smart derivative will settle the according cash flows as determined in the derivative contract specification. a defaultable otc derivative might end in a state ‘failure to pay’ if a settlement cannot be conducted. smart bond contract the life cycle of a bond can also make use of the function catalogue below. the interface enables the issuer to allocate and redeem the bond as well as settle coupon payments. on the other hand, it allows bondholders to interact with each other, conducting secondary market trades. it all boils down to a settlement phase, which needs to be pre-agreed by both parties or triggered by the issuer which can be processed in a completely frictionless way. specification methods the following methods specify a smart derivative contract’s trade initiation and settlement life cycle. for further information, please also look at the interface documentation isdc.sol. trade initiation phase: incepttrade a party can initiate a trade by providing the party address to trade with, trade data, trade position, payment amount for the trade and initial settlement data. only registered counterparties are allowed to use that function. function incepttrade(address _withparty, string memory _tradedata, int _position, int256 _paymentamount, string memory _initialsettlementdata) external; trade initiation phase: confirmtrade a counterparty can confirm a trade by providing its trade specification data, which then gets matched against the data stored from incepttrade call. function confirmtrade(address _withparty, string memory _tradedata, int _position, int256 _paymentamount, string memory _initialsettlementdata) external; trade settlement phase: initiatesettlement allows eligible participants (such as counterparties or a delegated agent) to trigger a settlement phase. function initiatesettlement() external; trade settlement phase: performsettlement valuation may be provided on-chain or off-chain via an external oracle service that calculates the settlement or coupon amounts and uses external market data. this method serves as a callback called from an external oracle providing settlement amount and used settlement data, which also get stored. the settlement amount will be checked according to contract terms, resulting in either a regular settlement or a termination of the trade. function performsettlement(int256 settlementamount, string memory settlementdata) external; trade settlement phase: aftertransfer this method either called back from the provided settlement token directly or from an eligible address completes the settlement transfer. this might result in a termination or start of the next settlement phase, depending on the provided success flag. function aftertransfer(uint256 transactionhash, bool success) external; trade termination: requesttermination allows an eligible party to request a mutual termination with a termination amount she is willing to pay function requesttradetermination(string memory tradeid, int256 _terminationpayment) external; trade termination: confirmtradetermination allows an eligible party to confirm a previously requested (mutual) trade termination, including termination payment value function confirmtradetermination(string memory tradeid, int256 _terminationpayment) external; trade events the following events are emitted during an sdc trade life-cycle. tradeincepted emitted on trade inception method ‘incepttrade’ event tradeincepted(address initiator, string tradeid, string tradedata); tradeconfirmed emitted on trade confirmation method ‘confirmtrade’ event tradeconfirmed(address confirmer, string tradeid); tradeactivated emitted when a trade is activated event tradeactivated(string tradeid); tradesettlementrequest emitted when a settlement is requested. may trigger the settlement phase. event tradesettlementrequest(string tradedata, string lastsettlementdata); tradesettlementphase emitted when the settlement phase is started. event tradesettlementphase(); tradeterminationrequest emitted when termination request is initiated by a counterparty event tradeterminationrequest(address cpaddress, string tradeid); tradeterminationconfirmed emitted when termination request is confirmed by a counterparty event tradeterminationconfirmed(address cpaddress, string tradeid); tradeterminated emitted when trade is terminated event tradeterminated(string cause); processhalted emitted when trade processing stops. event processhalted(); rationale the interface design and reference implementation are based on the following considerations: an sdc protocol enables interacting parties to initiate and process a financial transaction in a bilateral and deterministic manner. settlement and counterparty risk is managed by the contract. the provided interface specification is supposed to completely reflect the entire trade life cycle. the interface specification is generic enough to handle the case that parties process one or even multiple financial transactions (on a netted base) usually, the valuation of financial trades (e.g. otc derivatives) will require advanced valuation methodology to determine the market value. this is why the concept might rely on an external market data source and hosted valuation algorithms a pull-based valuation-based oracle pattern can be implemented by using the provided callback pattern (methods: initiatesettlement, performsettlement) the reference implementation sdc.sol is based on a state-machine pattern where the states also serve as guards (via modifiers) to check which method is allowed to be called at a particular given process and trade state state diagram of trade and process states sequence diagram of trade initiation and settlement life-cycle test cases life-cycle unit tests based on the sample implementation and usage of erc-20 token is provided. see file test/sdctests.js ). reference implementation an abstract contract class sdc.sol as well as a full reference implementation sdcpledgedbalance.sol for an otc-derivative is provided and is based on the erc-20 token standard. see folder /assets/contracts, more explanation on the implementation is provided inline. trade data specification (suggestion) please take a look at the provided xml file as a suggestion on how trade parameters could be stored. security considerations no known security issues up to now. copyright copyright and related rights waived via cc0. citation please cite this document as: christian fries (@cfries), peter kohl-landgraf (@pekola), alexandros korpis (@kourouta), "erc-6123: smart derivative contract [draft]," ethereum improvement proposals, no. 6123, december 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6123. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1276: eliminate difficulty bomb and adjust block reward on constantinople shift ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1276: eliminate difficulty bomb and adjust block reward on constantinople shift authors eos classic (@eosclassicteam) created 2018-07-31 discussion link https://ethereum-magicians.org/t/eip-1276-eliminate-difficulty-bomb-and-adjust-block-reward-on-constantinople-shift/908 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary the average block times are increasing due to the factor of difficulty logic well known as difficulty bomb. this eip proposes to eliminate the difficulty bomb forever and to reduce the block rewards with the constantinople fork, the second part of the metropolis fork. abstract starting with cnstntnpl_fork_blknum the client will calculate the difficulty without considering the current block number. furthermore, block rewards will be adjusted to a base of 2 eth, uncle and nephew rewards will be adjusted accordingly. motivation block time has been played a most important role on blockchain ecosystem, and it is being adjusted by the logic of mining difficulty calculation that is already implemented on the node client as a part of proof-of-work consensus. last year, average block time rapidly increased due to the wrong design of difficulty logic that is meant to be changed on the part of casper upgrade, however, implementation of casper has been delayed therefore it was inevitable to delay the difficulty bomb in order to prevent the significant delay of processing transactions on ethereum network. despite of the successful hardfork to delay the activation of difficulty bomb, activation of the difficulty bomb is expected to happen again on the upcoming period before implementing casper protocol on ethereum network. therefore, completely removing the difficulty bomb is the most proper way to response the block time increase instead of delaying it again. also decreasing the block mining reward along with difficulty bomb removal is expected to help the growth of the stable ethereum ecosystem, right now ethereum dominates 92% of the total hashrate share of ethash based chains, and this corresponds to a tremendous level of energy consumption. as this energy consumption has a correlated environmental cost the network participants have an ethical obligation to ensure this cost is not higher than necessary. at this time, the most direct way to reduce this cost is to lower the block reward in order to limit the appeal of eth mining. unchecked growth in hashrate is also counterproductive from a security standpoint. reducing the reward also decreases the likelihood of a miner driven chain split as ethereum approaches proof-of-stake. specification remove exponential component of difficulty adjustment for the purposes of calc_difficulty, simply remove the exponential difficulty adjustment component, epsilon, i.e. the int(2**((block.number // 100000) 2)). adjust block, uncle, and nephew rewards to ensure a constant ether issuance, adjust the block reward to new_block_reward, where new_block_reward = 2_000_000_000_000_000_000 if block.number >= cnstntnpl_fork_blknum else block.reward (2e18 wei, or 2,000,000,000,000,000,000 wei, or 2 eth). analogue, if an uncle is included in a block for block.number >= cnstntnpl_fork_blknum such that block.number uncle.number = k, the uncle reward is new_uncle_reward = (8 k) * new_block_reward / 8 this is the existing pre-constantinople formula for uncle rewards, simply adjusted with new_block_reward. the nephew reward for block.number >= cnstntnpl_fork_blknum is new_nephew_reward = new_block_reward / 32 this is the existing pre-constantinople formula for nephew rewards, simply adjusted with new_block_reward. rationale this will completely remove the difficulty bomb on difficulty adjustment algorithm without delaying the difficulty bomb again, therefore it is possible to prevent network delay on the beginning of 2019. this eip-1276 opposes directly the intent of eip-1234 which should be also considered in discussions. backwards compatibility this eip is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. therefore, it should be included in a scheduled hardfork at a certain block number. it’s suggested to include this eip in the second metropolis hard-fork, constantinople. test cases test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. implementation the implementation shall be created once the specification is to be accepted by the developers or implemented by the clients. copyright copyright and related rights waived via cc0. citation please cite this document as: eos classic (@eosclassicteam), "eip-1276: eliminate difficulty bomb and adjust block reward on constantinople shift [draft]," ethereum improvement proposals, no. 1276, july 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1276. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2696: javascript `request` method rpc transport ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: interface eip-2696: javascript `request` method rpc transport authors micah zoltu (@micahzoltu), erik marks (@rekmarks) created 2020-06-04 table of contents simple summary abstract motivation specification rfc-2119 interface results errors rationale security considerations copyright simple summary a standard for remote procedure calls between an ethereum provider and an ethereum client when both are able to interface with each other via a shared javascript object. abstract this standard provides the description of an object that is made available to javascript applications which they can use to communicate with the ethereum blockchain through. this standard only describes the transport mechanism, it does not specify the payloads that are valid nor does it specify how the client or the provider will discover or agree on payload content. how/where this ethereum object is exposed is left to future standards. motivation when working within a javascript runtime (such as nodejs, electron, browser, etc.) it may be possible for the runtime or a runtime plugin to inject objects into the runtime. someone authoring a runtime or a runtime plugin may choose to expose an ethereum provider to any javascript apps or scripts running within that runtime in order to provide indirect access to an ethereum-like blockchain and potentially signing tools. in order to achieve maximum compatibility between the provider and the client, a standard is necessary for what the shape of that object is. specification rfc-2119 the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc-2119. interface typescript interface definition: interface requestarguments { readonly method: string; readonly params?: readonly unknown[] | object; } interface ethereumprovider { request(args: requestarguments): promise } the provider must implement implement a request method on the exposed ethereumprovider object. the request method must be callable with a single parameter which contains the arguments for the request as defined in the typescript interface above. if the provider supports a json-rpc (https://www.jsonrpc.org/specification) request as specified elsewhere, then it must accept a request call for that json-rpc method with the requestarguments.method argument matching the json-rpc method string for the rpc call and the requestarguments.params matching the params object of the rpc call. the requestarguments.params should be encoded as a javascript object matching the specified json-rpc type, not encoded as a json string as would normally be the case when transporting json-rpc. example if the json-rpc request would contain a payload like: '{ "jsonrpc": "2.0", "id": 1, "method": "do_work", "params": [ 5, "hello" ] }' then the matching ethereumprovider.request call would be: declare const provider: ethereumprovider provider.request({ method: 'method', params: [ 5, 'hello' ] }) results if the provider supports a json-rpc request as specified elsewhere, then it must return an object that matches the expected result definition for the associated json-rpc request. example if the json-rpc response would contain a payload like: '{ "jsonrpc": "2.0", "id": 1, "result": { "color": "red", "value": 5 } }' then the matching ethereumprovider.request response would be: { color: 'red', value: 5 } errors interface providerrpcerror extends error { message: string; code: number; data?: unknown; } code message meaning 4001 user rejected request the user rejected the request. 4100 unauthorized the requested method and/or account has not been authorized by the user. 4200 unsupported method the provider does not support the requested method. 4900 disconnected the provider is disconnected from all chains. 4901 chain disconnected the provider is not connected to the requested chain. if the provider is unable to fulfill a request for any reason, it must resolve the promise as an error. the resolved error must be shaped as a providerrpcerror defined above whenever possible. while it is impossible to guaranteed that a javascript application will never throw an out of memory or stack overflow error, care should be taken to ensure that promise rejections conform to the above shape whenever possible. if a code is provided that is listed in the list above, or in the json-rpc specification (https://www.jsonrpc.org/specification#error_object), or in the associated json-rpc request standard being followed, then the error reason must align with the established meaning of that code and the message must match the provided message the data field may contain any data that is relevant to the error or would help the user understand or troubleshoot the error. rationale while this standard is perhaps not the greatest mechanism for communicating between an application and a blockchain, it is closely aligned with established practices within the community so migration from existing systems to this one should be relatively easy. most communication is currently done via json-rpc, so aligning with the json-rpc standard was desired to enable quick integration with existing systems. security considerations the relationship between ethereum provider and client is a trusted one, where it is assumed that the user implicitly trusts the ethereum provider which is how it managed to get injected into the client, or the client expressly pulled in a connection to it. copyright copyright and related rights waived via cc0. citation please cite this document as: micah zoltu (@micahzoltu), erik marks (@rekmarks), "eip-2696: javascript `request` method rpc transport," ethereum improvement proposals, no. 2696, june 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2696. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. devcon is back! | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search devcon is back! posted by vitalik buterin on september 24, 2015 events devcon 1 will be happening in london on november 9-13, a little over one hundred days since the ethereum network launched. over the last months, we’ve seen the network grow from a few hundred nodes starting on that one exciting and special night to a very substantial, globally deployed stable platform with thousands of devs pushing towards the decentralization revolution which motivates and inspires us. devcon will have three primary categories of topics: basic research and core protocols: including proof of stake, scalability, networking protocols, privacy and zero-knowledge proofs, as well as some of the more mathematical aspects of decentralized protocols like stablecoins, prediction markets and reputation systems. this part will be designed to be similar to an academic conference, in some ways in the spirit of cryptoeconomicon. dapp development: focusing on the practical challenges of developing applications on top of the ethereum platform and effective design patterns to optimize security, efficiency, developer time and the user experience. this part will be designed to be similar to a programming language developer convention, eg. http://nodejsconf.it/ industry and social implications: including iot, finance, government, supply chain tracking, notarization, identity and reputation. this part will be designed to appeal to industry and mainstream audiences, and particularly those from outside the ethereum ecosystem coming in with the goal of understanding what its features are and how their projects can benefit from using the technology, as well as other interested parties such as policymakers and investors. the conference will take place over 5 days from november 9-13 in london at the gibson hall. the first half of the week will focus on research and dapp development, and the second half of the week will focus on industry and social implications. we’ll also be discussing how development will continue now that the platform has launched, as well as the future direction of the foundation as an organization. we hope that over the course of the week you will be able to develop the understanding and make the connections you need to make the most of the opportunities ethereum presents. there will be keynotes from several of the core development team, updating you on progress and some exciting new projects, and as far as possible we’ll endeavor to livestream the event so that people who could not make it can come in too. one of the features of the week will be a focus on the dapps the community are producing a showcase, if you like, of all the great things happening on the ethereum platform. expect talks from development teams sharing what they have learned, and detailed talks about the new businesses and business models enabled by the ethereum platform. if you think that you have something to share, feel free to get in touch with us at info@ethereum.org. a website will soon be live at http://devcon.ethereum.org and we will add details on prices, agenda, sponsorships, etc as info becomes available. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-1890: commitment to sustainable ecosystem funding ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-1890: commitment to sustainable ecosystem funding authors gregory markou , kevin owocki , lane rettig created 2019-03-31 discussion link https://t.me/joinchat/dwed_xahl5hhvznyh2rnqa table of contents commitment to sustainable ecosystem funding simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright commitment to sustainable ecosystem funding simple summary ethereum currently provides a block reward to proof of work miners every block, but it does not capture any block rewards for ecosystem funding. this eip adds a simple mechanism for capturing a portion of block rewards for ecosystem funding as a credible commitment to doing so in future, but it does not actually capture any such rewards. abstract a mechanism that allows specification of two parameters, a beneficiary address and a per-block reward denominated in wei, that allows a portion of block rewards to be captured for the purpose of ecosystem funding. both values are set to zero. motivation in order for ethereum to succeed, it needs talented, motivated researchers and developers to continue to develop and maintain the platform. those talented researchers and developers deserve to be paid fairly for their work. at present there is no mechanism in the ethereum ecosystem that rewards r&d teams fairly for their work on the platform. we recognize that, while technically trivial, the real challenge in inflation-based funding is social: how to fairly capture, govern, and distribute block rewards. it will take time to work out the answer to these questions. for this reason, this eip only seeks to make a credible commitment on the part of core developers to securing the funding they need to keep ethereum alive and healthy by adding a mechanism to do so, but the actual amount of rewards captured remains at zero, i.e., there is no change at present to ethereum’s economics. raising the amount captured above zero would require a future eip. specification two new constants are introduced: beneficiary_address, an address, and devfund_block_reward, an amount denominated in wei. both are set to zero. beginning with block istanbul_block_height, devfund_block_reward wei is added to the balance of beneficiary_address at each block. we may optionally add another constant, decay_factor, which specifies a linear or exponenential decay factor that reduces the reward at every block > istanbul_block_height until it decays to zero. for simplicity, it has been omitted from this proposal. rationale we believe that the technical design of this eip is straightforward. the social rationale is explained in this article. backwards compatibility this eip has no impact on backwards compatibility. test cases this eip makes no changes to existing state transitions. existing consensus tests should be sufficient. implementation reference implementations are included for the trinity, go-ethereum, and parity clients. copyright copyright and related rights waived via cc0. citation please cite this document as: gregory markou , kevin owocki , lane rettig , "eip-1890: commitment to sustainable ecosystem funding [draft]," ethereum improvement proposals, no. 1890, march 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1890. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3403: partial removal of refunds ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-3403: partial removal of refunds authors vitalik buterin (@vbuterin), martin swende (@holiman) created 2021-03-16 discussion link https://ethereum-magicians.org/t/eip-3298-removal-of-refunds/5430 table of contents simple summary motivation the mutex usecase specification parameters rationale backwards compatibility test cases 2929 gas costs with eip-3403 partial refunds security considerations copyright simple summary remove gas refunds for selfdestruct, and restrict gas refunds for sstore to one specific case. motivation gas refunds for sstore and selfdestruct were originally introduced to motivate application developers to write applications that practice “good state hygiene”, clearing storage slots and contracts that are no longer needed. however, they are not widely used for this, and poor state hygiene continues to be the norm. it is now widely accepted that the only solution to state growth is some form of statelessness or state expiry, and if such a solution is implemented, then disused storage slots and contracts would start to be ignored automatically. gas refunds additionally have multiple harmful consequences: refunds give rise to gastoken. gastoken has benefits in moving gas space from low-fee periods to high-fee periods, but it also has downsides to the network, particularly in exacerbating state size (as state slots are effectively used as a “battery” to save up gas) and inefficiently clogging blockchain gas usage refunds increase block size variance. the theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction’s gas used). this is not fatal, but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than eip 1559 can. the mutex usecase there are two typical ways to implement mutexes: ‘0-1-0’ and ‘1-2-1. let’s see how they differ ‘0-1-0’: istanbul: 1612 berlin: 212 norefund: 20112 eip-3403: 1112 ‘1-2-1’: istanbul: 1612 berlin: 212 norefund: 3012 eip-3403: 3012 note: in reality, there are never a negative gas cost, since the refund is capped at 0.5 * gasused. however, these tables show the negative values, since a more real-world scenario would likely spend the extra gas on other operations.’ specification parameters constant value fork_block tbd sstore_refund_gas 19000 for blocks where block.number >= fork_block, the following changes apply. remove the selfdestruct refund. remove the sstore refund in all cases except for one specific case: if the new value and original value of the storage slot both equal 0 but the current value does not (those terms being defined as in eip-1283), refund sstore_refund_gas gas. rationale preserving refunds in the new = original = 0 != current case ensures that a few key use cases that deserve favorable gas cost treatment continue to receive favorable gas cost treatment, particularly: anti-reentrancy locks (typically flipped from 0 to 1 right before a child call begins, and then flipped back to 0 when the child call ends) erc20 approve-and-send (the “approved value” goes from zero to nonzero when the token transfer is approved, and then back to zero when the token transfer processes) it also preserves two key goals of eip 3298: gas tokens continue to be non-viable, because each 19000 refund is only possible because of 19000 extra gas that was paid for flipping that storage slot from zero to nonzero earlier in the same transaction, so you can’t clear some storage slots and use that saved gas to fill others. the total amount of gas spent on execution is capped at the gas limit. every 19000 refund for flipping a storage slot non from zero -> zero is only possible because of 19000 extra gas paid for flipping that slot from zero -> nonzero earlier in the same transaction; that gas paid for a storage write and expansion that were both reverted and so do not actually need to be applied to the merkle tree. hence, this extra gas does not contribute to risk. backwards compatibility refunds are currently only applied after transaction execution, so they cannot affect how much gas is available to any particular call frame during execution. hence, removing them will not break the ability of any code to execute, though it will render some applications economically nonviable. gas tokens in particular will become valueless. defi arbitrage bots, which today frequently use either established gas token schemes or a custom alternative to reduce on-chain costs, would benefit from rewriting their code to remove calls to these no-longer-functional gas storage mechanisms. test cases 2929 gas costs note, there is a difference between ‘hot’ and ‘cold’ slots. this table shows the values as of eip-2929 assuming that all touched storage slots were already ‘hot’ (the difference being a one-time cost of 2100 gas). code used gas refund original 1st 2nd 3rd effective gas (after refund) 0x60006000556000600055 212 0 0 0 0 212 0x60006000556001600055 20112 0 0 0 1 20112 0x60016000556000600055 20112 19900 0 1 0 212 0x60016000556002600055 20112 0 0 1 2 20112 0x60016000556001600055 20112 0 0 1 1 20112 0x60006000556000600055 3012 15000 1 0 0 -11988 0x60006000556001600055 3012 2800 1 0 1 212 0x60006000556002600055 3012 0 1 0 2 3012 0x60026000556000600055 3012 15000 1 2 0 -11988 0x60026000556003600055 3012 0 1 2 3 3012 0x60026000556001600055 3012 2800 1 2 1 212 0x60026000556002600055 3012 0 1 2 2 3012 0x60016000556000600055 3012 15000 1 1 0 -11988 0x60016000556002600055 3012 0 1 1 2 3012 0x60016000556001600055 212 0 1 1 1 212 0x600160005560006000556001600055 40118 19900 0 1 0 1 20218 0x600060005560016000556000600055 5918 17800 1 0 1 0 -11882 with eip-3403 partial refunds if refunds were to be partially removed, as specified here, this would be the comparative table. this table also assumes touched storage slots were already ‘hot’. code used gas refund original 1st 2nd 3rd effective gas (after refund) 0x60006000556000600055 212 0 0 0 0 212 0x60006000556001600055 20112 0 0 0 1 20112 0x60016000556000600055 20112 19000 0 1 0 1112 0x60016000556002600055 20112 0 0 1 2 20112 0x60016000556001600055 20112 0 0 1 1 20112 0x60006000556000600055 3012 0 1 0 0 3012 0x60006000556001600055 3012 0 1 0 1 3012 0x60006000556002600055 3012 0 1 0 2 3012 0x60026000556000600055 3012 0 1 2 0 3012 0x60026000556003600055 3012 0 1 2 3 3012 0x60026000556001600055 3012 0 1 2 1 3012 0x60026000556002600055 3012 0 1 2 2 3012 0x60016000556000600055 3012 0 1 1 0 3012 0x60016000556002600055 3012 0 1 1 2 3012 0x60016000556001600055 212 0 1 1 1 212 0x600160005560006000556001600055 40118 19000 0 1 0 1 21118 0x600060005560016000556000600055 5918 0 1 0 1 0 5918 security considerations refunds are not visible to transaction execution, so this should not have any impact on transaction execution logic. the maximum amount of gas that can be spent on execution in a block is limited to the gas limit, if we do not count zero-to-nonzero sstores that were later reset back to zero. it is okay to not count those, because if such an sstore is reset, storage is not expanded and the client does not need to actually adjust the merke tree; the gas consumption is refunded, but the effort normally required by the client to process those opcodes is also cancelled. clients should make sure to not do a storage write if new_value = original_value; this was a prudent optimization since the beginning of ethereum but it becomes more important now. copyright copyright and related rights waived via cc0. citation please cite this document as: vitalik buterin (@vbuterin), martin swende (@holiman), "eip-3403: partial removal of refunds [draft]," ethereum improvement proposals, no. 3403, march 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3403. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. frontier is coming what to expect, and how to prepare | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search frontier is coming what to expect, and how to prepare posted by stephan tual on july 22, 2015 protocol announcements we are only days away from launching 'frontier', the first milestone in the release of the ethereum project. frontier will be followed by 'homestead', 'metropolis' and 'serenity' throughout the coming year, each adding new features and improving the user friendliness and security of the platform. what is frontier? frontier is a live, but barebone implementation of the ethereum project. it's intended for technical users, specifically developers. during the frontier release, we expect early adopters and application developers to establish communities and start forming a live ecosystem. like their counterparts during the american frontier, these settlers will be presented with vast opportunities, but will also face many dangers. if building from source and command lines interfaces aren't your cup of tea, we strongly encourage you to wait for a more user-friendly release of the ethereum software before diving in. when is frontier going live? frontier is now feature complete and its codebase has been frozen for two weeks. as a team we are currently reviewing the final steps for the release, not all of them technical. there will be no countdown ethereum is not something that's centrally 'launched', but instead emerges from consensus. users will have to voluntarily download and run a specific version of the software, then generate and load the genesis block to join the official project's network. details on this process will be released soon. what can we expect in frontier? initial 'thawing': gas limits during the first few days the first software release of frontier will have a hardcoded gas limit per block of 5,000 gas. unlike the normal gas per block parameter, this special limit will not grow proportionally to the network usage effectively preventing transacting during the first few days. this 'thawing' period will enable miners to start their operations and early adopters to install their clients without having to 'rush'. after a few days (likely 3-4, but this could change), we'll release a small software update which all clients will have to install. this update will see the gas limit per block raised to 3 million, an initial number from which it will expand or contract as per the default miner settings. bugs, issues and complications we're very happy with how the 'olympic' testing phase of the ethereum testnet took shape. that said, the work on the frontier software is far from over. expect weekly updates which will give you access to better, more stable clients. many of the planned frontier gotchas (which included a chain reset at homestead, limiting mining rewards to 10%, and centralized checkpointing) were deemed unnecessary. however, there are still big differences between frontier and homestead. in frontier, we're going to have issues, we're going to have updates, and there will be bugs users are taking their chances when using the software. there will be big (big) warning messages before developers are able to even install it. in frontier, documentation is limited, and the tools provided require advanced technical skills. the canary contracts the canary contracts are simple switches holding a value equal to 0 or 1. each contract is controlled by a different member of the eth/dev team and will be updated to ‘1’ if the internal frontier disaster recovery team flags up a consensus issue, such as a fork. within each frontier client, a check is made after each block against 4 contracts. if two out of four of these contracts have a value switched from 0 to 1, mining stops and a message urging the user to update their client is displayed. this is to prevent "fire and forget" miners from preventing a chain upgrade. this process is centralized and will only run for the duration of frontier. it helps preventing the risk of a prolonged period (24h+) of outage. stats, status and badblock websites you probably are already familiar with our network stats monitor, https://stats.ethdev.com/. it gives a quick overview of the health of the network, block resolution time and gas statistics. if you’d like to explore it further, i’ve made a brief video explaining the various kpis. remember that participation in the stats page is voluntary, and nodes have to add themselves before they appear on the panel. in addition to the stats page, we will have a status page at https://status.ethdev.com/ (no link as the site is not live yet) which will gives a concise overview of any issue that might be affecting frontier. use it as your first port of call if you think something might not be right. finally, if any of the clients receive an invalid block, they will refuse to process it send it to the bad block website (aka ‘sentinel’). this could mean a bug, or something more serious, such as a fork. either way, this process will alert our developers to potential issues on the network. the website itself is public and available at https://badblocks.ethdev.com (currently operating on the testnet). a clean testnet during the last couple of months, the ethereum test network was pushed to its limits in order to test scalability and block propagation times. as part of this test we encouraged users to spam the network with transactions, contract creation code and call to contracts, at times reaching over 25 transactions per second. this has led the test network chain to grow to a rather unwieldy size, making it difficult for new users to catch up. for this reason, and shortly after the frontier release, there will be a new test network following the same rules as frontier. olympic rewards distribution during the olympic phase there were a number of rewards for various achievements including mining prowess. a large number of you participated and earned rewards a special mention goes to phistr90, dino and samuel lavery for their help during the stress tests. note that rewards will not be part of the frontier genesis block, but instead will be handed out by a foundation bot during the weeks following the release. how do i get started with frontier? the tools frontier and all its dependencies will be made available as a single line installer on our website at https://www.ethereum.org/. a single line installer will be provided for osx, linux and windows. of course, more advanced users will still be able to install everything from source, or use a binary build from our automated build bots. once frontier has been installed on their machines, users will need to generate the genesis block themselves, then load it into their frontier clients. a script and instructions on how to do this will be provided as part of the new ethereum website, as well as our various wikis. we’re often asked how existing users will switch from the test network to the live network: it will be done through a switch at the geth console (--networkid). by default the new build will aim to connect to the live network, to switch back to the test network you’ll simply indicate a network id of ‘0’. the documentation to get started with ethereum, the best place is our official gitbook. after consulting the gitbook, you can dig into the official solidity tutorial. for more in-depth information, please consult the main wiki, go client wiki and c++ client wiki. finally, if it's mining you'd like to learn more about, a mining faq and guide are regularly updated on our forums. getting help ethereum is an open source software project and as such, all help is provided through the community channels. if you face issues, the first port of call should be our forums, followed by our ethereum chat channels. if you're on the other hand are experiencing problems specific to your ether sale wallet, such as not being able to load your pre sale purchase, the helpdesk address will continue operating throughout frontier (and probably beyond). and of course, you can also find help locally at one of our 115 meetups around the world if your city isn’t listed, we encourage you to create one. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-5585: erc-721 nft authorization ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: erc erc-5585: erc-721 nft authorization allows nft owners to authorize other users to use their nfts. authors veega labs (@veegalabsofficial), sean ng (@ngveega), tiger (@tiger0x), fred (@apan), fov cao (@fovcao) created 2022-08-15 last call deadline 2023-10-10 requires eip-721 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification contract interface rationale backwards compatibility security considerations copyright abstract this eip separates the erc-721 nft’s commercial usage rights from its ownership to allow for the independent management of those rights. motivation most nfts have a simplified ownership verification mechanism, with a sole owner of an nft. under this model, other rights, such as display, or creating derivative works or distribution, are not possible to grant, limiting the value and commercialization of nfts. therefore, the separation of an nft’s ownership and user rights can enhance its commercial value. commercial right is a broad concept based on the copyright, including the rights of copy, display, distribution, renting, commercial use, modify, reproduce and sublicense etc. with the development of the metaverse, nfts are becoming more diverse, with new use cases such as digital collections, virtual real estate, music, art, social media, and digital asset of all kinds. the copyright and authorization based on nfts are becoming a potential business form. specification the keywords “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may” and “optional” in this document are to be interpreted as described in rfc 2119. contract interface interface ierc5585 { struct userrecord { address user; string[] rights; uint256 expires } /// @notice get all available rights of this nft project /// @return all the rights that can be authorized to the user function getrights() external view returns(string[]); /// @notice nft holder authorizes all the rights of the nft to a user for a specified period of time /// @dev the zero address indicates there is no user /// @param tokenid the nft which is authorized /// @param user the user to whom the nft is authorized /// @param duration the period of time the authorization lasts function authorizeuser(uint256 tokenid, address user, uint duration) external; /// @notice nft holder authorizes specific rights to a user for a specified period of time /// @dev the zero address indicates there is no user. it will throw exception when the rights are not defined by this nft project /// @param tokenid the nft which is authorized /// @param user the user to whom the nft is authorized /// @param rights rights autorised to the user, such as renting, distribution or display etc /// @param duration the period of time the authorization lasts function authorizeuser(uint256 tokenid, address user, string[] rights, uint duration) external; /// @notice the user of the nft transfers his rights to the new user /// @dev the zero address indicates there is no user /// @param tokenid the rights of this nft is transferred to the new user /// @param newuser the new user function transferuserrights(uint256 tokenid, address newuser) external; /// @notice nft holder extends the duration of authorization /// @dev the zero address indicates there is no user. it will throw exception when the rights are not defined by this nft project /// @param tokenid the nft which has been authorized /// @param user the user to whom the nft has been authorized /// @param duration the new duration of the authorization function extendduration(uint256 tokenid, address user, uint duration) external; /// @notice nft holder updates the rights of authorization /// @dev the zero address indicates there is no user /// @param tokenid the nft which has been authorized /// @param user the user to whom the nft has been authorized /// @param rights new rights autorised to the user function updateuserrights(uint256 tokenid, address user, string[] rights) external; /// @notice get the authorization expired time of the specified nft and user /// @dev the zero address indicates there is no user /// @param tokenid the nft to get the user expires for /// @param user the user who has been authorized /// @return the authorization expired time function getexpires(uint256 tokenid, address user) external view returns(uint); /// @notice get the rights of the specified nft and user /// @dev the zero address indicates there is no user /// @param tokenid the nft to get the rights /// @param user the user who has been authorized /// @return the rights has been authorized function getuserrights(uint256 tokenid, address user) external view returns(string[]); /// @notice the contract owner can update the number of users that can be authorized per nft /// @param userlimit the number of users set by operators only function updateuserlimit(unit256 userlimit) external onlyowner; /// @notice resetallowed flag can be updated by contract owner to control whether the authorization can be revoked or not /// @param resetallowed it is the boolean flag function updateresetallowed(bool resetallowed) external onlyowner; /// @notice check if the token is available for authorization /// @dev throws if tokenid is not a valid nft /// @param tokenid the nft to be checked the availability /// @return true or false whether the nft is available for authorization or not function checkauthorizationavailability(uint256 tokenid) public view returns(bool); /// @notice clear authorization of a specified user /// @dev the zero address indicates there is no user. the function works when resetallowed is true and it will throw exception when false /// @param tokenid the nft on which the authorization based /// @param user the user whose authorization will be cleared function resetuser(uint256 tokenid, address user) external; /// @notice emitted when the user of a nft is changed or the authorization expires time is updated /// param tokenid the nft on which the authorization based /// param indexed user the user to whom the nft authorized /// @param rights rights autorised to the user /// param expires the expires time of the authorization event authorizeuser(uint256 indexed tokenid, address indexed user, string[] rights, uint expires); /// @notice emitted when the number of users that can be authorized per nft is updated /// @param userlimit the number of users set by operators only event updateuserlimit(unit256 userlimit); } the getrights() function may be implemented as pure and view. the authorizeuser(uint256 tokenid, address user, uint duration) function may be implemented as public or external. the authorizeuser(uint256 tokenid, address user, string[] rights; uint duration) function may be implemented as public or external. the transferuserrights(uint256 tokenid, address newuser) function may be implemented as public or external. the extendduration(uint256 tokenid, address user, uint duration) function may be implemented as public or external. the updateuserrights(uint256 tokenid, address user, string[] rights) function may be implemented as public or external. the getexpires(uint256 tokenid, address user) function may be implemented as pure or view. the getuserrights(uint256 tokenid, address user) function may be implemented as pure and view. the updateuserlimit(unit256 userlimit) function may be implemented aspublic or external. the updateresetallowed(bool resetallowed) function may be implemented as public or external. the checkauthorizationavailability(uint256 tokenid) function may be implemented as pure or view. the resetuser(uint256 tokenid, address user) function may be implemented as public or external. the authorizeuser event must be emitted when the user of a nft is changed or the authorization expires time is updated. the updateuserlimit event must be emitted when the number of users that can be authorized per nft is updated. rationale first of all, nft contract owner can set the maximum number of authorized users to each nft and whether the nft owner can cancel the authorization at any time to protect the interests of the parties involved. secondly, there is a resetallowed flag to control the rights between the nft owner and the users for the contract owner. if the flag is set to true, then the nft owner can disable usage rights of all authorized users at any time. thirdly, the rights within the user record struct is used to store what rights has been authorized to a user by the nft owner, in other words, the nft owner can authorize a user with specific rights and update it when necessary. finally, this design can be seamlessly integrated with third parties. it is an extension of erc-721, therefore it can be easily integrated into a new nft project. other projects can directly interact with these interfaces and functions to implement their own types of transactions. for example, an announcement platform could use this eip to allow all nft owners to make authorization or deauthorization at any time. backwards compatibility this standard is compatible with erc-721 since it is an extension of it. security considerations when the resetallowed flag is false, which means the authorization can not be revoked by nft owner during the period of authorization, users of the eip need to make sure the authorization fee can be fairly assigned if the nft was sold to a new holder. here is a solution for taking reference: the authorization fee paid by the users can be held in an escrow contract for a period of time depending on the duration of the authorization. for example, if the authorization duration is 12 months and the fee in total is 10 eth, then if the nft is transferred after 3 months, then only 2.5 eth would be sent and the remaining 7.5 eth would be refunded. copyright copyright and related rights waived via cc0. citation please cite this document as: veega labs (@veegalabsofficial), sean ng (@ngveega), tiger (@tiger0x), fred (@apan), fov cao (@fovcao), "erc-5585: erc-721 nft authorization [draft]," ethereum improvement proposals, no. 5585, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5585. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5902: smart contract event hooks ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5902: smart contract event hooks format that allows contracts to semi-autonoumously respond to events emitted by other contracts authors simon brown (@orbmis) created 2022-11-09 discussion link https://ethereum-magicians.org/t/idea-smart-contract-event-hooks-standard/11503 requires eip-712 table of contents abstract motivation collateralised lending protocols automated market makers dao voting scheduled function calls recurring payments coordination via delegation specification registering a publisher updating a hook removing a hook registering a subscriber updating a subscription removing a subscription publishing an event relayers verifying a hook event interfaces rationale security considerations griefing attacks front-running attacks relayer competition optimal fees without an auction relayer transaction batching replay attacks cross-chain messaging copyright abstract this eip proposes a standard for creating “hooks” that allow a smart contract function to be called automatically in response to a trigger fired by another contract, by using a public relayer network as a messaging bus. while there are many similar solutions in existence already, this proposal describes a simple yet powerful primitive that can be employed by many applications in an open, permissionless and decentralized manner. it relies on two interfaces, one for a publisher contract and one for a subscriber contract. the publisher contract emits events that are picked up by “relayers”, who are independent entities that subscribe to “hook” events on publisher contracts, and call a function on the respective subscriber contracts, whenever a hook event is fired by the publisher contracts. whenever a relayer calls the respective subscriber’s contract with the details of the hook event emitted by the publisher contract, they are paid a fee by the subscriber. both the publisher and subscriber contracts are registered in a central registry smart contract that relayers can use to discover hooks. motivation there exists a number of use cases that require some off-chain party to monitor the chain and respond to on-chain events by broadcasting a transaction. such cases usually require some off-chain process to run alongside an ethereum node in order to subscribe to events emitted by smart contract, and then execute some logic in response and subsequently broadcast a transaction to the network. this requires an ethereum node and an open websocket connection to some long-running process that may only be used infrequently, resulting in a sub-optimal use of resources. this proposal would allow for a smart contract to contain the logic it needs to respond to events without having to store that logic in some off-chain process. the smart contract can subscribe to events fired by other smart contracts and would only execute the required logic when it is needed. this method would suit any contract logic that does not require off-chain computation, but usually requires an off-chain process to monitor the chain state. with this approach, subscribers do not need their own dedicated off-chain processes for monitoring and responding to contract events. instead, a single incentivized relayer can subscribe to many different events on behalf of multiple different subscriber contracts. examples of use cases that would benefit from this scheme include: collateralised lending protocols collateralised lending protocols or stablecoins can emit events whenever they receive price oracle updates, which would allow borrowers to automatically “top-up” their open positions to avoid liquidation. for example, maker uses the “medianizer” smart contract which maintains a whitelist of price feed contracts which are allowed to post price updates. every time a new price update is received, the median of all feed prices is re-computed and the medianized value is updated. in this case, the medianizer smart contract could fire a hook event that would allow subscriber contracts to decide to re-collateralize their cdps. automated market makers amm liquidity pools could fire a hook event whenever liquidity is added or removed. this could allow a subscriber smart contracts to add or remove liquidity once the total pool liquidity reaches a certain point. amms can fire a hook whenever there is a trade within a trading pair, emitting the time-weighted-price-oracle update via an hook event. subscribers can use this to create an automated limit-order-book type contract to buy/sell tokens once an asset’s spot price breaches a pre-specified threshold. dao voting hook events can be emitted by a dao governance contract to signal that a proposal has been published, voted on, carried or vetoed, and would allow any subscriber contract to automatically respond accordingly. for example, to execute some smart contract function whenever a specific proposal has passed, such as an approval for payment of funds. scheduled function calls a scheduler service can be created whereby a subscriber can register for a scheduled funtion call, this could be done using unix cron format and the service can fire events from a smart contract on separate threads. subscriber contracts can subscriber to the respective threads in order to subscribe to certain schedules (e.g. daily, weekly, hourly etc.), and could even register customer cron schedules. recurring payments a service provider can fire hook events that will allow subscriber contracts to automatically pay their service fees on a regular schedule. once the subscriber contracts receive a hook event, they can call a function on the service provider’s contract to transfer funds due. coordination via delegation hook event payloads can contain any arbitrary data, this means you can use things like the delegatable framework to sign off-chain delegations which can faciliate a chain of authorized entities to publish valid hook events. you can also use things like bls threshold signatures, to facilitate multiple off-chain publishers to authorize the firing of a hook. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. registering a publisher both the publisher and subscriber contracts must register in a specific register contract, similarly to how smart contracts register an interface in the erc-1820 contract. the registry contract must must use a deterministic deployment mechanism, i.e. using a factory contract and a specific salt. to register a publisher contract’s hook, the registerhook function must be called on the registry contract. the parameters that need to be supplied are: (address) the publisher contract address (uint256) the thread id that the hooks events will reference (a single contract can fire hook events with any number of threads, subscribers can choose which threads to subscribe to) (bytes) the public key associated with the hook events (optional) when the registerhook function is called on the registry contract, the registry contract must make a downstream call to the publisher contract address, by calling the publisher contract’s verifyeventhookregistration function, with the same arguments as passed to the registerhook function on the registry contract. the verifyeventhookregistration function in the publisher contract must return true in order to indicate that the contract will allow itself to be added to the registry as a publisher. the registry contract must emit a hookregistered event to indicate that a new publisher contract has been added. updating a hook publishers may want to update the details associated with a hook event, or indeed remove support for a hook event completely. the registry contract must implement the updatepublisher function to allow for an existing publisher contract to be updated in the registry. the registry contract must emit a publisherupdated event to indicate that the publisher contract was updated. removing a hook to remove a previously registered hook, the function removehook function must be called on the registry contract, with the same parameters as the updatehook function. the registry contract must emit a hookremoved event with the same parameters as passed to the ‘removehook’ function and the msg.sender value. registering a subscriber to register a subscriber to a hook, the registersubscriber function must be called on the registry contract with the following parameters: (address) the publisher contract address (bytes32) the subscriber contract address (uint256) the thread id to subscribe to (uint256) the fee that the subscriber is willing to pay to get updates (uint256) the maximum gas that the subscriber will allow for updates, to prevent griefing attacks, or 0 to indicate no maximum (uint256) the maximum gas price that the subscriber is willing to repay the relayer on top of the fee, or 0 to indicate no rebates (uint256) the chain id that the subscriber wants updates from (address) the address of the token that the fee will be paid in or 0x0 for the chain’s native asset (e.g. eth, matic etc.) the subscriber contract may implement gas refunds on top of the fixed fee per update. where a subscriber chooses to do this, then they should specify the maximum gas and maximum gas price parameters in order to protect themselves from griefing attacks. this is so that a malicious or careless relay doesn’t set an exorbitantly high gas price and ends up draining the subscriber contracts. subscriber contracts can otherwise choose to set a fee that is estimated to be sufficiently high to cover gas fees. note that while the chain id and the token address were not included in the original version of the spec, the simple addition of these two parameters allows for leveraging the relayers for cross chain messages, should the subscriber wish to do this, and also allows for paying relayer fees in various tokens. updating a subscription to update a subscription, the updatesubscriber function must be called with the same set of parameters as the registersubscriber function. this might be done in order to cancel a subscription, or to change the subscription fee. note that the updatesubscriber function must maintain the same msg.sender that the registersubscriber function was called with. removing a subscription to remove a previously registered subscription, the function removesubscriber must be called on the registry contract, with the same parameters as the updatesubscriber function, but without the fee parameter (i.e. publisher and subscriber contract addresses and thread id). the fee will be subsequently set to 0 to indicate that the subscriber no longer wants updates for this subscription. the registry contract must emit a subscriptionremoved event with publisher contract address, subscriber contract address and the thread id as topics. publishing an event a publisher contract should emit a hook event from at least one function. the emitted event must be called hook and must contain the following parameters: uint256 (indexed) threadid uint256 (indexed) nonce bytes32 digest bytes payload bytes32 checksum the nonce value must be incremented every time a hook event is fired by a publisher contract. every hook event must have a unique nonce value. the nonce property is initiated to 1, but the first hook event ever fired must be set to 2. this is to prevent ambiguity between an uninitiated nonce variable and a nonce variable that is explicitly initiated to zero. the digest parameter of the event must be the keccak256 hash of the payload, and the checksum must be the keccak256 hash of the concatenation of the digest with the current blockheight, e.g.: bytes32 checksum = keccak256(abi.encodepacked(digest, block.number)); the hook event can be triggered by a function call from any eoa or external contract. this allows the payload to be created dynamically within the publisher contract. the subscriber contract should call the verifyeventhook function on the publisher contract to verify that the received hook payload is valid. the payload may be passed to the function firing the hook event instead of being generated within the publisher contract itself, but if a signature is provided it must sign a hash of the payload, and it is strongly recommended to use the eip-712 standard, and to follow the data structure outlined at the end of this proposal. this signature should be verified by the subscribers to ensure they are getting authentic events. the signature must correspond to the public key that was registered with the event. with this approach, the signature should be placed at the start of the payload (e.g. bytes 0 to 65 for an ecdsa signature with r, s, v properties). this method of verification can be used for cross-chain hook events, where subscribers will not be able to call the verifyhookevent of the publisher contract on another chain. the payload must be passed to subscribers as a byte array in calldata. the subscriber smart contract should convert the byte array into the required data type. for example, if the payload is a snark proof, the publisher would need to serialize the variables into a byte array, and the subscriber smart contract would need to deserialize it on the other end, e.g.: struct snarkproof { uint256[2] a; uint256[2][2] b; uint256[2] c; uint256[1] input; } snarkproof memory zkproof = abi.decode(payload, snarkproof); relayers relayers are independent parties that listen to hook events on publisher smart contracts. relayers retrieve a list of subscribers for different hooks from the registry, and listen for hook events being fired on the publisher contracts. once a hook event has been fired by a publisher smart contract, relayers can decide to relay the hook event’s payload to the subscriber contracts by broadcasting a transaction that executes the subscriber contract’s verifyhook function. relayers are incentivised to do this because it is expected that the subscriber contract will remunerate them with eth, or some other asset. relayers should simulate the transaction locally before broadcasting it to make sure that the subscriber contract has sufficient balance for payment of the fee. this requires subscriber contracts to maintain a balance of eth (or some asset) in order to provision payment of relayer fees. a subscriber contract may decide to revert a transaction based on some logic, which subsequently allows the subscriber contract to conditionally respond to events, depending on the data in the payload. in this case the relayer will simulate the transaction locally and determine not to relay the hook event to the subscriber contract. verifying a hook event the verifyhook function of the subscriber contracts should include logic to ensure that they are retrieving authentic events. in the case where the hook event contains a signature, then subscriber contracts should create a hash of the required parameters, and should verify that the signature in the hook event is valid against the derived hash and the publisher’s public key (see the reference implemenetation for an example). the hook function should also verify the nonce of the hook event and record it internally, in order to prevent replay attacks. for hook events without signatures, the subscriber contract should call the verifyhookevent on the publisher contract in order to verify that the hook event is valid. the publisher smart contract must implement the verifyhookevent, which accepts the hash of the payload, the thread id, the nonce, and the block height associated with the hook event, and returns a boolean value to indicate the hook event’s authenticity. interfaces iregistry.sol /// @title iregistry /// @dev implements the registry contract interface iregistry { /// @dev registers a new hook event by a publisher /// @param publishercontract the address of the publisher contract /// @param threadid the id of the thread these hook events will be fired on /// @param signingkey the public key that corresponds to the signature of externally generated payloads (optional) /// @return returns true if the hook is successfully registered function registerhook( address publishercontract, uint256 threadid, bytes calldata signingkey ) external returns (bool); /// @dev verifies a hook with the publisher smart contract before adding it to the registry /// @param publisheraddress the address of the publisher contract /// @param threadid the id of the thread these hook events will be fired on /// @param signingkey the public key used to verify the hook signatures /// @return returns true if the hook is successfully verified function verifyhook( address publisheraddress, uint256 threadid, bytes calldata signingkey ) external returns (bool); /// @dev update a previously registered hook event /// @dev can be used to transfer hook authorization to a new address /// @dev to remove a hook, transfer it to the burn address /// @param publishercontract the address of the publisher contract /// @param threadid the id of the thread these hook events will be fired on /// @param signingkey the public key used to verify the hook signatures /// @return returns true if the hook is successfully updated function updatehook( address publishercontract, uint256 threadid, bytes calldata signingkey ) external returns (bool); /// @dev remove a previously registered hook event /// @param publishercontract the address of the publisher contract /// @param threadid the id of the thread these hook events will be fired on /// @param signingkey the public key used to verify the hook signatures /// @return returns true if the hook is successfully updated function removehook( address publishercontract, uint256 threadid, bytes calldata signingkey ) external returns (bool); /// @dev registers a subscriber to a hook event /// @param publishercontract the address of the publisher contract /// @param subscribercontract the address of the contract subscribing to the event hooks /// @param threadid the id of the thread these hook events will be fired on /// @param fee the fee that the subscriber contract will pay the relayer /// @param maxgas the maximum gas that the subscriber allow to spend, to prevent griefing attacks /// @param maxgasprice the maximum gas price that the subscriber is willing to rebate /// @param chainid the chain id that the subscriber wants updates on /// @param feetoken the address of the token that the fee will be paid in or 0x0 for the chain's native asset (e.g. eth) /// @return returns true if the subscriber is successfully registered function registersubscriber( address publishercontract, address subscribercontract, uint256 threadid, uint256 fee, uint256 maxgas, uint256 maxgasprice, uint256 chainid, address feetoken ) external returns (bool); /// @dev registers a subscriber to a hook event /// @param publishercontract the address of the publisher contract /// @param subscribercontract the address of the contract subscribing to the event hooks /// @param threadid the id of the thread these hook events will be fired on /// @param fee the fee that the subscriber contract will pay the relayer /// @return returns true if the subscriber is successfully updated function updatesubscriber( address publishercontract, address subscribercontract, uint256 threadid, uint256 fee ) external returns (bool); /// @dev removes a subscription to a hook event /// @param publishercontract the address of the publisher contract /// @param subscribercontract the address of the contract subscribing to the event hooks /// @param threadid the id of the thread these hook events will be fired on /// @return returns true if the subscriber is subscription removed function removesubscription( address publishercontract, address subscribercontract, uint256 threadid ) external returns (bool); } ipublisher.sol /// @title ipublisher /// @dev implements a publisher contract interface ipublisher { /// @dev example of a function that fires a hook event when it is called /// @param payload the actual payload of the hook event /// @param digest hash of the hook event payload that was signed /// @param threadid the thread number to fire the hook event on function firehook( bytes calldata payload, bytes32 digest, uint256 threadid ) external; /// @dev adds / updates a new hook event internally /// @param threadid the thread id of the hook /// @param signingkey the public key associated with the private key that signs the hook events function addhook(uint256 threadid, bytes calldata signingkey) external; /// @dev called by the registry contract when registering a hook, used to verify the hook is valid before adding /// @param threadid the thread id of the hook /// @param signingkey the public key associated with the private key that signs the hook events /// @return returns true if the hook is valid and is ok to add to the registry function verifyeventhookregistration( uint256 threadid, bytes calldata signingkey ) external view returns (bool); /// @dev returns true if the specified hook is valid /// @param payloadhash the hash of the hook's data payload /// @param threadid the thread id of the hook /// @param nonce the nonce of the current thread /// @param blockheight the blockheight that the hook was fired at /// @return returns true if the specified hook is valid function verifyeventhook( bytes32 payloadhash, uint256 threadid, uint256 nonce, uint256 blockheight ) external view returns (bool); } isubscriber.sol /// @title isubscriber /// @dev implements a subscriber contract interface isubscriber { /// @dev example of a function that is called when a hook is fired by a publisher /// @param publisher the address of the publisher contract in order to verify hook event with /// @param payload hash of the hook event payload that was signed /// @param threadid the id of the thread this hook was fired on /// @param nonce unique nonce of this hook /// @param blockheight the block height at which the hook event was fired function verifyhook( address publisher, bytes calldata payload, uint256 threadid, uint256 nonce, uint256 blockheight ) external; } rationale the rationale for this design is that it allows smart contract developers to write contract logic that listens and responds to events fired in other smart contracts, without requiring them to run some dedicated off-chain process to achieve this. this best suits any simple smart contract logic that runs relatively infrequently in response to events in other contracts. this improves on the existing solutions to achieve a pub/sub design pattern. to elaborate: a number of service providers currently offer “webhooks” as a way to subscribe to events emitted by smart contracts, by having some api endpoint called when the events are emitted, or alternatively offer some serverless feature that can be triggered by some smart contract event. this approach works very well, but it does require that some api endpoint or serverless function be always available, which may require some dedicated server / process, which in turn will need to have some private key, and some amount of eth in order to re-broadcast transactions, no to mention the requirement to maintain an account with some third party provider. this approach offers a more suitable alternative for when an “always-on” server instance is not desirable, e.g. in the case that it will be called infrequently. this proposal incorporates a decentralized market-driven relay network, and this decision is based on the fact that this is a highly scalable approach. conversely, it is possible to implement this functionality without resorting to a market-driven approach, by simply defining a standard for contracts to allow other contracts to subscribe directly. that approach is conceptually simpler, but has its drawbacks, in so far as it requires a publisher contract to record subscribers in its own state, creating an overhead for data management, upgradeability etc. that approach would also require the publisher to call the verifyhook function on each subscriber contract, which will incur potentially significant gas costs for the publisher contract. security considerations griefing attacks it is imperative that subscriber contracts trust the publisher contracts not to fire events that hold no intrinsic interest or value for them, as it is possible that malicious publisher contracts can publish a large number of events that will in turn drain the eth from the subscriber contracts. front-running attacks it is advised not to rely on signatures alone to validate hook events. it is important for publishers and subscribers of hooks to be aware that it is possible for a relayer to relay hook events before they are published, by examining the publisher’s transaction in the mempool before it actually executes in the publisher’s smart contract. the normal flow is for a “trigger” transaction to call a function in the publisher smart contract, which in turn fires an event which is then picked up by relayers. competitive relayers will observe that it is possible to pluck the signature and payload from the trigger transaction in the public mempool and simply relay it to subscriber contracts before the trigger transaction has been actually included in a block. in fact, it is possible that the subscriber contracts process the event before the trigger transaction is processed, based purely on gas fee dynamics. this can mitigated against by subscriber contracts calling the verifyeventhook function on the publisher contract when they receive a hook event. another risk from front-running affects relayers, whereby the relayer’s transactions to the subscriber contracts can be front-run by generalized mev searchers in the mempool. it is likely that this sort of mev capture will occur in the public mempool, and therefore it is advised that relayers use private channels to block builders to mitigate against this issue. relayer competition by broadcasting transactions to a segregated mempool, relayers protect themselves from front-running by generalized mev bots, but their transactions can still fail due to competition from other relayers. if two or more relayers decide to start relaying hook events from the same publisher to the same subscribers, then the relay transactions with the highest gas price will be executed before the others. this will result in the other relayer’s transactions potentially failing on-chain, by being included later in the same block. for now, there are certain transaction optimization services that will prevent transactions from failing on-chain, which will offer a solution to this problem, though this is out-of-scope for this document. optimal fees the fees that are paid to relayers are at the discretion of the subscribers, but it can be non-trivial to set fees to their optimal level, especially when considering volatile gas fees and competition between relayers. this will result in subscribers setting fees to a perceived “safe” level, which they are confident will incentivize relayers to relay hook events. this will inevitably lead to poor price discovery and subscribers over-paying for updates. the best way to solve this problem is through an auction mechanism that would allow relayers to bid against each other for the right to relay a transaction, which would guarantee that subscribers are paying the optimal price for their updates. describing an auction mechanism that would satisfy this requirements is out of scope for this proposal, but there exists proposals for general purpose auction mechanisms that can faciliate this without introducing undue latency. one exampe of such as proposal is suave from flashbots, and there will likely be several others in time. without an auction in order to cultivate and maintain a reliable relayer market without the use of an auction mechanism, subscriber contracts would need to implement logic to either rebate any gas fees up to a specified limit, (while still allowing for execution of hook updates under normal conditions). another approach would be to implement a logical condition that checks the gas price of the transaction that is calling the verifyhook function, to ensure that the gas price does not effectively reduce the fee to zero. this would require that the subscriber smart contract has some knowledge of the approximate gas used by it’s verifyhook function, and to check that the condition minfee >= fee (gasprice * gasused) is true. this will mitigate against competitive bidding that would drive the effective relayer fee to zero, by ensuring that there is some minimum fee below which the effective fee is not allowed to drop. this would mean that the highest gas price that can be paid before the transaction reverts is fee minfee + ε where ε ~= 1 gwei. this will require careful estimation of the gas cost of the verifyhook function and an awareness that the gas used may change over time as the contract’s state changes. the key insight with this approach is that competition between relayers will result in the fee that the subscribers pay always being the maximum, which is why the use of an auction mechanism is preferable. relayer transaction batching another important consideration is with batching of hook events. relayers are logically incentivized to batch hook updates to save on gas, seeing as gas savings amount to 21,000 * n where n is the number of hooks being processed in a block by a single relayer. if a relayer decides to batch multiple hook event updates to various subscriber contracts into a single transaction, via a multi-call proxy contract, then they increase the risk of the entire batch failing on-chain if even one of the transactions in the batch fails on-chain. for example, if relayer a batches x number of hook updates, and relayer b batches y number of hook updates, it is possible that relayer a’s batch is included in the same block in front of relayer b’s batch, and if both batches contain at least one duplicate, (i.e. the same hook event to the same subscriber), then this will cause relayer b’s batch transaction to revert on-chain. this is an important consideration for relayers, and suggests that relayers should have access to some sort of bundle simulation service to identify conflicting transactions before they occur. replay attacks when using signature verification, it is advised to use the eip-712 standard in order to prevent cross network replay attacks, where the same contract deployed on more than one network can have its hook events pushed to subscribers on other networks, e.g. a publisher contract on polygon can fire a hook event that could be relayed to a subscriber contract on gnosis chain. whereas the keys used to sign the hook events should ideally be unique, in reality this may not always be the case. for this reason, it is recommended to use erc-721 typed data signatures. in this case the process that initiates the hook should create the signature according to the following data structure: const domain = [ { name: "name", type: "string" }, { name: "version", type: "string" }, { name: "chainid", type: "uint256" }, { name: "verifyingcontract", type: "address" }, { name: "salt", type: "bytes32" } ] const hook = [ { name: "payload", type: "string" }, { type: "uint256", name: "nonce" }, { type: "uint256", name: "blockheight" }, { type: "uint256", name: "threadid" }, ] const domaindata = { name: "name of publisher dapp", version: "1", chainid: parseint(web3.version.network, 10), verifyingcontract: "0x123456789abcedf....publisher contract address", salt: "0x123456789abcedf....random hash unique to publisher contract" } const message = { payload: "bytes array serialized payload" nonce: 1, blockheight: 999999, threadid: 1, } const eip712typeddata = { types: { eip712domain: domain, hook: hook }, domain: domaindata, primarytype: "hook", message: message } note: please refer to the unit tests in the reference implmenetation for an example of how a hook event should be constructed properly by the publisher. replay attacks can also occur on the same network that the event hook was fired, by simply re-broadcasting an event hook that was already broadcast previously. for this reason, subscriber contracts should check that a nonce is included in the event hook being received, and record the nonce in the contract’s state. if the hook nonce is not valid, or has already been recorded, the transaction should revert. cross-chain messaging there is also the possibility to leverage the chainid for more than preventing replay attacks, but also for accepting messages from other chains. in this use-case the subscriber contracts should register on the same chain that the subscriber contract is deployed on, and should set the chainid to the chain it wants to receive hook events from. copyright copyright and related rights waived via cc0. citation please cite this document as: simon brown (@orbmis), "erc-5902: smart contract event hooks [draft]," ethereum improvement proposals, no. 5902, november 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5902. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-2569: saving and displaying image onchain for universal tokens ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2569: saving and displaying image onchain for universal tokens a set of interfaces to save an svg image in ethereum, and to retrieve the image file from ethereum for universal tokens. authors hua zhang (@dgczhh), yuefei tan (@whtyfhas), derek zhou (@zhous), ran xing (@lemontreeran) created 2020-03-28 discussion link https://ethereum-magicians.org/t/erc-2569-saving-and-displaying-image-onchain-for-universal-tokens/4167 table of contents abstract motivation specification rationale backwards compatibility reference implementation copyright abstract this set of interfaces allow a smart contract to save an svg image in ethereum and to retrieve an svg image from ethereum for fungible tokens, non-fungible tokens and tokens based on standards that will be developed in the future. the interface set has two interfaces: one to save an svg file in ethereum and the other to retrieve an svg file from ethereum. typical applications include but not limited to: a solution for storage of a fungible token’s icon. a solution for storage of a non-fungible token’s icon. a solution for storage of the icon/logo of a dao’s reputation token. motivation the erc-721 token standard is a popular standard to define a non-fungible token in ethereum. this standard is widely used to specify a crypto gift, crypto medal, crypto collectible etc. the most famous use case is the cryptokitty. in most of these applications an image is attached to an erc-721 token. for example, in the cryptokitty case each kitty has a unique image. while the token’s code is saved in ethereum permanently, the image attached to the token is not. the existing solutions still keep such an image in a centralized server instead of ethereum. when these applications display an image for a token they retrieve the token’s information from ethereum and search the centralized server for the token’s associated image by using the token’s information. although this is an applicable way to display an image for a token, the image is still vulnerable to risks of being damaged or lost when saved in a centralized server. hence we propose a set of interfaces to save an image for a universal token in ethereum to keep the image permanent and tamper-resistant, and to retrieve an image for a universal token from ethereum. specification an eip-2569 compatible contract must have a method with the signature gettokenimagesvg(uint256) view returns (string memory) and a method with the signature settokenimagesvg(uint256 tokenid, string memory imagesvg) internal. these methods define how a smart contract saves an image for a universal token in ethereum which keeps the image permanent and tamper-resistant, and how a smart contract retrieves an image from ethereum for a universal token. by calling the methods users should access an svg image. gettokenimagesvg(uint256 tokenid) external view returns (string memory): for an erc-721 or erc-1155 token or a token implemented by a contract which has a member “id” to specify its token type or token index we define an interface to get an svg image by using the token’s id number. for an erc-20 token or a token implemented by a contract which doesn’t have a member “id” to specify its token type or token index we define an interface to get an svg image for it if the token has a member variable string to save the image. it has the following parameter: tokenid: for a non-fungible token such as an erc-721 token or a multi-token such as an erc-1155 token which has a member “id” to specify its token type or token index our proposed interface assigns an svg image’s file content to a string variable of the token’s contract and associates the svg image to this “id” number. this unique id is used to access its svg image in both a “set” operation and a “get” operation. for a fungible token such as an erc-20 token no such an id is needed and our proposed interface just assigns an svg image’s file content to a string variable of the token’s contract. settokenimagesvg(uint256 tokenid, string memory imagesvg) internal: for an erc-721 or erc-1155 token or a token implemented by a contract which has a member “id” to specify its token type or token index we define an interface to associate an svg image to the token’s id number. for an erc-20 token or a token implemented by a contract which doesn’t have a member “id” to specify its token type or token index we define an interface to assign an svg image to a member variable string of this token’s contract. it has the following two parameters: tokenid: for a non-fungible token such as an erc-721 token or a multi-token such as an erc-1155 token which has a member “id” to specify its token type or token index our proposed interface assigns an svg image’s file content to a string variable of the token’s contract and associates the svg image to this “id” number. this unique id is used to access its svg image in both a “set” operation and a “get” operation. for a fungible token such as an erc-20 token no such an id is needed and our proposed interface just assigns an svg image’s file content to a string variable of the token’s contract. imagesvg: we use a string variable to save an svg image file’s content. an svg image that will be saved in the imagesvg string should include at least two attributes:”name”, “desc”(description). the procedure to save an image for a token in ethereum is as follows: step1: define a string variable or an array of strings to hold an image or an array of images. step 2: define a function to set an (svg) image’s file content or an array of image file’s contents to the string variable or the array of strings. step 1: for a token such as an erc-721 or erc-1155 token which has a member variable “id” to specify a token type or index and a member variable string to keep an (svg) image associated with the “id”, retrieve the (svg) image from ethereum by calling our proposed “get” interface with the token’s id; for a token which doesn’t have a member variable “id” to specify a token type of index but has a member variable string to keep an (svg) image, retrieve the (svg) image from ethereum by calling our proposed “get” without an “id”. rationale after bitcoin was created people have found ways to keep information permanent and tamper-resistant by encoding text messages they want to preserve permanently and tamper-resistantly in blockchain transactions. however existing applications only do this for text information and there are no solutions to keep an image permanent and tamper-resistant. one of the most significant reasons for not doing so is that in general the size of an image is much bigger than the size of a text file, thus the gas needed to save an image in ethereum would exceed a block’s gas limit. however this changed a lot after the svg(scalable vector graphics) specification was developed by w3c since 1999. the svg specification offers several advantages (for more details about the advantages please refer to a reference link:https://en.wikipedia.org/wiki/scalable_vector_graphics) over raster images. one of these advantages is its compact file-size. “compact file-size – pixel-based images are saved at a large size from the start because you can only retain the quality when you make the image smaller, but not when you make it larger. this can impact a site’s download speed. since svgs are scalable, they can be saved at a minimal file size”. this feature well fixes the painpoint of saving an image file in ethereum, therefore we think saving an svg image in ethereum is a good solution for keep the image permanent and tamper-resistant. in most erc-721 related dapps they display an image for a non-fungible token. in most erc-20 related dapps they don’t have an image for a fungible token. we think displaying an image for a token either based on existing token standards such as erc-20, erc-721, erc-1155 or based on future standards is needed in many use cases. therefore those dapps which currently don’t display an image for a token will eventually need such a function. however with regard to most of the existing dapps which can display an image for a token they save such an image in a centralized server which, we think, is just a compromised solution. by utilizing the svg specification we think converting a token’s image to an svg image and saving it in ethereum provides a better solution for dapps to access an image for a token. this solution not only works for tokens based on erc-721, erc-1155 and erc-20 but will work for tokens based on future standards. backwards compatibility there are no backward compatibility issues. reference implementation tokenid: a token index in an erc-721 token or a token type/index in an erc-1155 token. it is a uint256 variable. imagesvg: an svg image’s file content. it is a string variable. note: the svg image should include at least three attributes:”name”, “description” and “issuer”. settokenimagesvg: interface to set an svg image to a token with or without an id number. gettokenimagesvg: interface to get an svg image for a token with or without an id number. we propose to add three sol files in the existing erc-721 implementation. here are the details for the proposed sol files. // ----ierc721getimagesvg.sol ------------------------pragma solidity ^0.5.0; import "@openzeppelin/contracts/token/erc721/ierc721.sol"; /** * @title erc-721 non-fungible token standard, optional retrieving svg image extension * @dev see https://eips.ethereum.org/eips/eip-721 */ contract ierc721getimagesvg is ierc721 { function gettokenimagesvg(uint256 tokenid) external view returns (string memory); } // ----erc721getimagesvg.sol ------------------------pragma solidity ^0.5.0; import "@openzeppelin/contracts/gsn/context.sol"; import "@openzeppelin/contracts/token/erc721/./erc721.sol"; import "@openzeppelin/contracts/introspection/erc165.sol"; import "./ierc721getimagesvg.sol"; contract erc721getimagesvg is context, erc165, erc721, ierc721getimagesvg { // mapping for token images mapping(uint256 => string) private _tokenimagesvgs; /* * bytes4(keccak256('gettokenimagesvg(uint256)')) == 0x87d2f48c * * => 0x87d2f48c == 0x87d2f48c */ bytes4 private constant _interface_id_erc721_get_token_image_svg = 0x87d2f48c; /** * @dev constructor function */ constructor () public { // register the supported interfaces to conform to erc721 via erc165 _registerinterface(_interface_id_erc721_get_token_image_svg); } /** * @dev returns an svg image for a given token id. * throws if the token id does not exist. may return an empty string. * @param tokenid uint256 id of the token to query */ function gettokenimagesvg(uint256 tokenid) external view returns (string memory) { require(_exists(tokenid), "erc721getimagesvg: svg image query for nonexistent token"); return _tokenimagesvgs[tokenid]; } /** * @dev internal function to set the token svg image for a given token. * reverts if the token id does not exist. * @param tokenid uint256 id of the token to set its svg image * @param imagesvg string svg to assign */ function settokenimagesvg(uint256 tokenid, string memory imagesvg) internal { require(_exists(tokenid), "erc721getimagesvg: svg image set of nonexistent token"); _tokenimagesvgs[tokenid] = imagesvg; } } // ----erc721imagesvgmintable.sol ------------------------pragma solidity ^0.5.0; import "@openzeppelin/contracts/token/erc721/erc721metadata.sol"; import "@openzeppelin/contracts/access/roles/minterrole.sol"; import "./erc721getimagesvg.sol"; /** * @title erc721imagesvgmintable * @dev erc721 minting logic with imagesvg. */ contract erc721imagesvgmintable is erc721, erc721metadata, erc721getimagesvg, minterrole { /** * @dev function to mint tokens. * @param to the address that will receive the minted tokens. * @param tokenid the token id to mint. * @param tokenimagesvg the token svg image of the minted token. * @return a boolean that indicates if the operation was successful. */ function mintwithtokenimagesvg(address to, uint256 tokenid, string memory tokenimagesvg) public onlyminter returns (bool) { _mint(to, tokenid); settokenimagesvg(tokenid, tokenimagesvg); return true; } } we propose to add three sol files in the existing erc-1155 implementation. here are the details for the proposed sol files. // ----ierc1155getimagesvg.sol ------------------------pragma solidity ^0.5.0; import "./ierc1155.sol"; /** * @title erc-1155 multi token standard, retrieving svg image for a token * @dev see https://github.com/ethereum/eips/blob/master/eips/eip-1155.md */ contract ierc1155getimagesvg is ierc1155 { function gettokenimagesvg(uint256 tokenid) external view returns (string memory); } // ----erc1155getimagesvg.sol ------------------------pragma solidity ^0.5.0; import "./erc1155.sol"; import "./ierc1155getimagesvg.sol"; contract erc1155getimagesvg is erc165, erc1155, ierc1155getimagesvg { // mapping for token images mapping(uint256 => string) private _tokenimagesvgs; /* * bytes4(keccak256('gettokenimagesvg(uint256)')) == 0x87d2f48c * * => 0x87d2f48c == 0x87d2f48c */ bytes4 private constant _interface_id_erc1155_get_token_image_svg = 0x87d2f48c; /** * @dev constructor function */ constructor () public { // register the supported interfaces to conform to erc1155 via erc165 _registerinterface(_interface_id_erc1155_get_token_image_svg); } /** * @dev returns an svg image for a given token id. * throws if the token id does not exist. may return an empty string. * @param tokenid uint256 id of the token to query */ function gettokenimagesvg(uint256 tokenid) external view returns (string memory) { require(_exists(tokenid), "erc1155getimagesvg: svg image query for nonexistent token"); return _tokenimagesvgs[tokenid]; } /** * @dev internal function to set the token svg image for a given token. * reverts if the token id does not exist. * @param tokenid uint256 id of the token to set its svg image * @param imagesvg string svg to assign */ function settokenimagesvg(uint256 tokenid, string memory imagesvg) internal { require(_exists(tokenid), "erc1155getimagesvg: svg image set of nonexistent token"); _tokenimagesvgs[tokenid] = imagesvg; } } // ----erc1155mixedfungiblewithsvgmintable.sol ------------------------pragma solidity ^0.5.0; import "./erc1155mixedfungiblemintable.sol"; import "./erc1155getimagesvg.sol"; /** @dev mintable form of erc1155 with svg images shows how easy it is to mint new items with svg images */ contract erc1155mixedfungiblewithsvgmintable is erc1155, erc1155mixedfungiblemintable, erc1155getimagesvg { /** * @dev function to mint non-fungible tokens. * @param _to the address that will receive the minted tokens. * @param _type the token type to mint. * @param tokenimagesvg the token svg image of the minted token. */ function mintnonfungiblewithimagesvg(uint256 _type, address[] calldata _to, string memory tokenimagesvg) external creatoronly(_type) { mintnonfungible(_type, _to); settokenimagesvg(_type, tokenimagesvg); } /** * @dev function to mint fungible tokens. * @param _to the address that will receive the minted tokens. * @param _id the token type to mint. * @param _quantities the number of tokens for a type to mint. * @param tokenimagesvg the token svg image of the minted token. */ function mintfungiblewithimagesvg(uint256 _id, address[] calldata _to, uint256[] calldata _quantities, string memory tokenimagesvg) external creatoronly(_id) { mintfungible(_id, _to, _quantities, tokenimagesvg) { settokenimagesvg(_id, tokenimagesvg); } } we propose to add three sol files in the existing erc-20 implementation. here are the details for the proposed sol files. // ----ierc20getimagesvg.sol ------------------------pragma solidity ^0.5.0; import "@openzeppelin/contracts/token/erc20/ierc20.sol"; /** * @title erc-20 fungible token standard, retrieving svg image for a token * @dev see https://github.com/openzeppelin/openzeppelin-contracts/blob/master/contracts/token/erc20/erc20.sol */ contract ierc20getimagesvg is ierc20 { function gettokenimagesvg() external view returns (string memory); } // ----erc20getimagesvg.sol ------------------------pragma solidity ^0.5.0; import "@openzeppelin/contracts/token/erc20/erc20.sol"; import "./ierc20getimagesvg.sol"; contract erc20getimagesvg is erc20, ierc20getimagesvg { string private _tokenimagesvg; //将图片实现写在构造器中 constructor(string calldata svgcode) public { _tokenimagesvg = svgcode } /** * @dev returns an svg image. */ function gettokenimagesvg() external view returns (string memory) { return _tokenimagesvg; } } copyright copyright and related rights waived via cc0. citation please cite this document as: hua zhang (@dgczhh), yuefei tan (@whtyfhas), derek zhou (@zhous), ran xing (@lemontreeran), "erc-2569: saving and displaying image onchain for universal tokens [draft]," ethereum improvement proposals, no. 2569, march 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2569. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5749: the 'window.evmproviders' object ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: interface eip-5749: the 'window.evmproviders' object add 'window.evmproviders' and suggest the eventual removal of 'window.ethereum' authors kosala hemachandra (@kvhnuke) created 2022-10-04 requires eip-1193 table of contents abstract motivation specification window.evmproviders={} rationale backwards compatibility reference implementation injection retrieving all evm providers security considerations copyright abstract a javascript ethereum provider interface injection that will allow for the interoperability of multiple browser wallets at the same time. replacing window.ethereum with window.evmproviders is a simple solution that will provide multiple benefits including: improving user experience, encouraging innovation in the space, removing race conditions and a ‘winner-takes-most’ environment as well as lowering barriers for user adoption. motivation at present, window.ethereum is the prevailing method by which ethereum-compatible applications interact with injected wallets. this originated with mist wallet in 2015 to interact with other applications. with the proliferation of both applications and wallets, window.ethereum has unintended negative consequences: window.ethereum only permits one wallet to be injected at a time, resulting in a race condition between two or more wallets. this creates an inconsistent connection behavior that makes having and using more than one browser wallet unpredictable and impractical. the current solution is for wallets to inject their own namespaces, but this is not feasible as every application would need to be made aware of any wallet that might be used. the aforementioned race condition means users are disincentivized to experiment with new wallets. this creates a ‘winner-takes-most’ wallet market across evm chains which forces application developers to optimize for a particular wallet experience. the ‘winner-takes-most’ wallet environment that results from the window.ethereum standard hinders innovation because it creates a barrier to adoption. new entrants into the space have difficulty gaining traction against legacy players because users can have no more than one injected wallet. with new entrants crowded out, legacy wallet providers are put under little pressure to innovate. wallets continue to be the most fundamental tool for interacting with blockchains. a homogeneous wallet experience in ethereum and evm chains risks stunting ux improvement across the ecosystem and will allow other ecosystems that are more encouraging of competition and innovation to move ahead. some wallets that currently use window.ethereum as of august, 2022. currently a user will have inconsistent behavior if they use multiple of these wallets in a single browser. metamask coinbase wallet enkrypt trust wallet rainbow replacing window.ethereum with window.evmproviders will allow solutions such as web3modal and web3onboard to display all injected wallets the user has installed. this will simpify the ux and remove race conditions between wallet providers in case multiple wallets are installed. over time, as window.evmproviders supplants the current standard and removes barriers to choice, we can hope to see a wallet landscape more reflective of user preference. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. window.evmproviders={} /** * represents the assets needed to display a wallet */ interface providerinfo { /** * a uuidv4 unique to the wallet provider. * * this must remain the same across versions but must be different across channels. for example, metamask, trust wallet and enkrypt should each have different uuids, but metamask 10.22.2 and metamask 9.8.1 should have the same uuid. * * @readonly */ uuid: string; /** * the name of the wallet provider (e.g. `metamask` or `enkrypt`) * * @readonly */ name: string; /** * a base64 encoded svg image. * * base64 is defined in rfc 4648. * * @readonly */ icon: `data:image/svg+xml;base64,${string}`; /** * a description of the wallet provider. * * @readonly */ description: string; } /** * represents the new provider with info type that extends the eip1193 provider */ interface providerwithinfo extends eip1193provider { info: providerinfo; } type eip1193provider is documented at eip-1193 /** * the type of `window.evmproviders` */ interface evmproviders { /** * the key is recommended to be the name of the extension in snake_case. it must contain only lowercase letters, numbers, and underscores. */ [index: string]: providerwithinfo; } rationale standardizing a providerinfo type allows determining the necessary information to populate a wallet selection popup. this is particularly useful for web3 onboarding libraries such as web3modal, web3react, and web3onboard. the name evmproviders was chosen to include other evm-compliant chains. the svg image format was chosen for its flexibility, lightweight nature, and dynamic resizing capabilities. backwards compatibility this eip doesn’t require supplanting window.ethereum, so it doesn’t directly break existing applications. however, the recommended behavior of eventually supplanting window.ethereum would break existing applications that rely on it. reference implementation injection const provider: providerwithinfo = [your wallet] window.evmproviders = window.evmproviders || {}; window.evmproviders[name] = provider retrieving all evm providers const allproviders = object.values(window.evmproviders) security considerations the security considerations of eip-1193 apply to this eip. the use of svg images introduces a cross-site scripting risk as they can include javascript code. applications and libraries must render svg images using the tag to ensure no js executions can happen. copyright copyright and related rights waived via cc0. citation please cite this document as: kosala hemachandra (@kvhnuke), "eip-5749: the 'window.evmproviders' object," ethereum improvement proposals, no. 5749, october 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5749. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7572: contract-level metadata via `contracturi()` ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7572: contract-level metadata via `contracturi()` specifying and updating contract-level metadata authors devin finzer (@dfinzer), alex atallah (@alexanderatallah), ryan ghods (@ryanio) created 2023-12-06 discussion link https://ethereum-magicians.org/t/erc-contract-level-metadata-via-contracturi/17157 table of contents abstract motivation specification schema for contracturi rationale backwards compatibility reference implementation security considerations copyright abstract this specification standardizes contracturi() to return contract-level metadata. this is useful for dapps and offchain indexers to show rich information about a contract, such as its name, description and image, without specifying it manually or individually for each dapp. motivation dapps have included supported for contracturi() for years without an erc to reference. this standard also introduces the event contracturiupdated() to signal when to update the metadata. 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. the contract must implement the below interface: interface ierc7572 { function contracturi() external view returns (string memory); event contracturiupdated(); } the string returned from contracturi() may be an offchain resource or onchain json data string (data:application/json;utf8,{}). the contracturiupdated() event should be emitted on updates to the contract metadata for offchain indexers to query the contract. if the underlying contract additionally provides a name() method, the metadata returned by contracturi()’s name property is recommended to take precedence. this enables contract creators to update their contract name with an event that notifies of the update. schema for contracturi the schema for the json returned from contracturi() must conform to: { "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "properties": { "name": { "type": "string", "description": "the name of the contract." }, "description": { "type": "string", "description": "the description of the contract." }, "image": { "type": "string", "format": "uri", "description": "a uri pointing to a resource with mime type image/* that represents the contract, typically displayed as a profile picture for the contract." }, "banner_image": { "type": "string", "format": "uri", "description": "a uri pointing to a resource with mime type image/* that represents the contract, displayed as a banner image for the contract." }, "featured_image": { "type": "string", "format": "uri", "description": "a uri pointing to a resource with mime type image/* that represents the featured image for the contract, typically used for a highlight section. the aspect ratio of the image should be 1:1." }, "external_link": { "type": "string", "format": "uri", "description": "the external link of the contract." }, "collaborators": { "type": "array", "items": { "type": "string", "description": "an ethereum address representing an authorized editor of the contract." }, "description": "an array of ethereum addresses representing collaborators (authorized editors) of the contract." } }, "required": ["name"] } example: { "name": "example contract", "description": "your description here", "image": "ipfs://qmtngv3jx2hhfbjqx9rnktxj2xv2xqctbdxori5rj3a46e", "banner_image": "ipfs://qmdchmvnmsq4u7ovkhud7wusezgnwumuty5ruqx57ayp6h", "featured_image": "ipfs://qms9m6e1e1nfiomm8dy1wmznn2frh2wdjeqjfwextqxct8", "external_link": "https://project-website.com", "collaborators": ["0x388c818ca8b9251b393131c08a736a67ccb19297"] } future ercs may inherit this one to add more properties to the schema for standardization. rationale the method name contracturi() was chosen based on its existing implementation in dapps. the event contracturiupdated() is specified to help offchain indexers to know when to refetch the metadata. backwards compatibility as a new erc, no backwards compatibility issues are present. reference implementation contract mycollectible is erc721, iercxxxx { string _contracturi = "ipfs://qmtngv3jx2hhfbjqx9rnktxj2xv2xqdtbvxori5rj3a46e" // or e.g. "https://external-link-url.com/my-contract-metadata.json"; function contracturi() external view returns (string memory) { return _contracturi; // or e.g. for onchain: string memory json = '{"name": "creatures","description":"..."}'; return string.concat("data:application/json;utf8,", json); } /// @dev suggested setter, not explicitly specified as part of this erc function setcontracturi(string memory newuri) external onlyowner { _contracturi = newuri; emit contracturiupdated(); } } security considerations addresses specified as collaborators should be expected to receive admin-level functionality for updating contract information on dapps that implement this standard. copyright copyright and related rights waived via cc0. citation please cite this document as: devin finzer (@dfinzer), alex atallah (@alexanderatallah), ryan ghods (@ryanio), "erc-7572: contract-level metadata via `contracturi()` [draft]," ethereum improvement proposals, no. 7572, december 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7572. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. gav’s ethereum ðξv update iv | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search gav’s ethereum ðξv update iv posted by gavin wood on december 15, 2014 research & development time for another update! so quite a bit has happened following ðξvcon-0, our internal developer's conference. the conference itself was a great time to get all the developers together and really get to know each other, dissipate a lot of information (back to back presentations for 5 days!) and chat over a lot of ideas. the comms team will be releasing each of the presentations as fast as ian can get them nicely polished. during the time since the last update, much has happened including, finally, the release of the ethereum ðξv website, ethdev.com. though relatively simple as present, there are great plans to extend this into a developer's portal in which you'll be able to browse the bug bounty programme, look at and, ultimately follow tutorials, look up documentation, find the latest binaries for each platform and see the progress of builds. as usual i have been mostly between switzerland, the uk and berlin, during this time. now that ðξv-berlin is settled in the hub, we have a great collaboration space in which volunteers can work, collaborate, bond and socialise alongside our more formal hires. of late, i have been working to finish up the formal specification of ethereum, the yellow paper, and make it up to date with the latest protocol changes in order that the security audit get underway. together we have been putting the finishing touches on seventh, and likely final, proof-of-concept code, delayed largely due to a desire to make it the final poc release for protocol changes. i've also been doing some nice core refactoring and documentation, specifically removing two long standing dislikes of mine, the state::create and state::call methods and making the state class nicer for creating custom states useful when developing contracts. you can expect to see the fruits of this work in milestone ii of mix, ethereum's official ide. ongoing recruitment on that note, i'm happy to announce that we have hired arkadiy paronyan, a talented developer originally from russia who will be working with yann on the mix ide. he's got off to a great start on his first week helping on the front-end with the second milestone. i'm also very pleased to announce that we hired gustav simonsson. being an expert erlang with go experience with considerable expertise in network programming and security reviewing, he will initially be working with jutta on the go code base security audit before joining the go team. we also have another two recruits: dimitri khoklov and jason colby. i first met jason in the fateful week back last january when the early ethereum collaborators got together for a week before the north american bitcoin conference where vitalik gave the first public talk about ethereum. jason, who has moved to berlin from his home in new hampshire, is mostly working alongside aeron and christian to help to look after the hub and looking after various bits of administration that need to be done. dimitri, who works from tver in russia is helping flesh out our unit tests with christoph, ultimately aiming towards full code coverage. we have several more recruits that i'd love to mention but can't announce quite yet watch this space... (: ongoing projects i'm happy to say that after a busy weekend, marek, caktux, nick and sven have managed to get the build bot, our ci system, building on all three platforms cleanly again. a special shout goes out to marek who tirelessly fought with cmake and msvc to bend the windows platform to his will. well done to all involved. christian continues to power through on the solidity project, aided now by lefteris who is focusing on parsing and packaging the natspec documentation. the latest feature to be added allows for the creation of new contracts in a beautiful manner with the new keyword. alex and sven are beginning to work on the project of introducing network well-formedness into the p2p subsystem using the salient parts of the well-proven kademlia dht design. we should begin seeing some of this stuff in the code base within before the year-end. i'm also happy to announce that the first successful message was sent between go & c++ clients on our messaging/hash-table hybrid system, codenamed whisper. though only at an early proof-of-concept stage, the api is reasonably robust and fixed, so largely ready to prototype applications on. new projects marian is the lucky guy who has been tasked with developing out what will be our awesome web-based c&c deck. this will provide a public website whose back-end connects to a bunch of nodes around the world and displays real-time information on network status including chain length and a chain-fork early warning system. though accessible by anyone, we will of course have a dedicated monitor on at all times for this page at the hub. sven, jutta and heiko have also begun a most interesting and important project: the ethereum stress-testing project. designed to study and test the network in a range of real-life adverse situations prior to release, they will construct infrastructure allowing the setup of many (10s, 100s, even 1000s of) nodes each individually remote-controllable and able to simulate circumstances such as isp attacks, net splits, rogue clients, arrival and departure of large amounts of hash-power and measure attributes like block & transaction propagation times and patterns, uncle rates and fork lengths. a project to watch out for. conclusions the next time i write this i hope to have released poc-7 and be on the way to the alpha release (not to mention have the yellow paper out). i expect jeff will be doing an update concerning the go side of things soon enough. until then, watch out for the poc-7 release and mine some testnet ether! previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-1504: upgradable smart contract ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1504: upgradable smart contract authors kaidong wu , chuqiao ren , ruthia he , yun ma , xuanzhe liu created 2018-10-17 discussion link https://github.com/ethereum/eips/issues/1503 table of contents simple summary abstract motivation specification handler contract and handler interface data contract upgrader contract (optional) caveats rationale data contract and handler contract upgrader contract and voting mechanism gas and complexity (regarding the enumeration extension) community consensus implementations copyright simple summary a standard interface/guideline that makes a smart contract upgradable. abstract ethereum smart contracts have suffered a number of security issues in the past few years. the cost of fixing such a bug in smart contract is significant; for example, the consequences of the dao attack in june 2016 caused tremendous financial loss and the hard fork of ethereum blockchain. the following standard makes it possible to upgrade a standard api within smart contracts. this standard provides basic functionalities to upgrade the operations of the contract without data migration. to ensure the decentralization/community interests, it also contains a voting mechanism to control the upgrading process. motivation smart contract is immutable after deployment. if any security risk is identified or program bug is detected, developers always have to destruct the old contract, deploy a new one and potentially migrate the data (hard fork) to the new contract. in some cases, deploying a smart contract with bugs and potential security vulnerabilities can cause a significant amount of financial loss. we propose this upgradable contract to fix the current situation. with the upgradable contract, developers can deploy a new version of smart contract after previous deployment and retain the data at the same time. for example, after an erc20-compliant token contract is deployed, the users exploit a vulnerability in the source code. without the support of upgradable contract, developers have to fix this issue by deploy a new, secured contract otherwise the attackers would take advantage of the security hole, which may cause a tremendous financial loss. a challenge is how to migrate data from the old contract to a new one. with the upgradable contract below, this will become relatively easy as developers only have to upgrade the handler contract to fix bugs while the data contract will remain the same. specification the upgradable contract consists of three parts: handler contract (implements handler interface) defines operations and provides services. this contract can be upgraded; data contract keeps the resources (data) and is controlled by the handler contract; upgrader contract (optional) deals with the voting mechanism and upgrades the handler contract. the voters are pre-defined by the contract owner. the following codes are exact copies of the erc-1504 upgradable smart contract. handler contract and handler interface functions of the handler contract vary with requirements, so developers would better design interfaces for handler contracts to limit them and make sure external applications are always supported. below is the specification of handler interface. in the handler interface we define the following actions: initialize the data contract; register the upgrader contract address; destruct the handler contract after upgrading is done; verify the current handler is the working one → it should always return true. developers have to define their business-related functions as well. /// handler interface. /// handler defines business related functions. /// use the interface to ensure that your external services are always supported. /// because of function live(), we design ihandler as an abstract contract rather than a true interface. contract ihandler { /// initialize the data contarct. /// @param _str value of exmstr of data contract. /// @param _int value of exmint of data contract. /// @param _array value of exmarray of data contract. function initialize (string _str, uint256 _int, uint16 [] _array) public; /// register upgrader contract address. /// @param _upgraderaddr address of the upgrader contract. function registerupgrader (address _upgraderaddr) external; /// upgrader contract calls this to check if it is registered. /// @return if the upgrader contract is registered. function isupgraderregistered () external view returns(bool); /// handler has been upgraded so the original one has to self-destruct. function done() external; /// check if the handler contract is a working handler contract. /// it is used to prove the contract is a handler contract. /// @return always true. function live() external pure returns(bool) { return true; } /** functions define functions here */ /** events add events here */ } the process of deploying a handler contract: deploy data contract; deploy a handler contract at a given address specified in the data contract; register the handler contract address by calling sethandler() in the data contract, or use an upgrader contract to switch the handler contract, which requires that data contract is initialized; initialize data contract if haven’t done it already. data contract below is the specification of data contract. there are three parts in the data contract: administrator data: owner’s address, handler contract’s address and a boolean indicating whether the contract is initialized or not; upgrader data: upgrader contract’s address, upgrade proposal’s submission timestamp and proposal’s time period; resource data: all other resources that the contract needs to keep and manage. /// data contract contract datacontract { /** management data */ /// owner and handler contract address private owner; address private handleraddr; /// ready? bool private valid; /** upgrader data */ address private upgraderaddr; uint256 private proposalblocknumber; uint256 private proposalperiod; /// upgrading status of the handler contract enum upgradingstatus { /// can be upgraded done, /// in upgrading inprogress, /// another proposal is in progress blocked, /// expired expired, /// original handler contract error error } /** data resources define variables here */ /** modifiers */ /// check if msg.sender is the handler contract. it is used for setters. /// if fail, throw permissionexception. modifier onlyhandler; /// check if msg.sender is not permitted to call getters. it is used for getters (if necessary). /// if fail, throw getterpermissionexception. modifier allowedaddress; /// check if the contract is working. /// it is used for all functions providing services after initialization. /// if fail, throw uninitializationexception. modifier ready; /** management functions */ /// initializer. just the handler contract can call it. /// @param _str default value of this.exmstr. /// @param _int default value of this.exmint. /// @param _array default value of this.exmarray. /// exception permissionexception msg.sender is not the handler contract. /// exception reinitializationexception contract has been initialized. /// @return if the initialization succeeds. function initialize (string _str, uint256 _int, uint16 [] _array) external onlyhandler returns(bool); /// set handler contract for the contract. owner must set one to initialize the data contract. /// handler can be set by owner or upgrader contract. /// @param _handleraddr address of a deployed handler contract. /// @param _originalhandleraddr address of the original handler contract, only used when an upgrader contract want to set the handler contract. /// exception permissionexception msg.sender is not the owner nor a registered upgrader contract. /// exception upgraderexception upgrader contract does not provide a right address of the original handler contract. /// @return if handler contract is successfully set. function sethandler (address _handleraddr, address _originalhandleraddr) external returns(bool); /** upgrader contract functions */ /// register an upgrader contract in the contract. /// if a proposal has not been accepted until proposalblocknumber + proposalperiod, it can be replaced by a new one. /// @param _upgraderaddr address of a deployed upgrader contract. /// exception permissionexception msg.sender is not the owner. /// exception upgraderconflictexception another upgrader contract is working. /// @return if upgrader contract is successfully registered. function startupgrading (address _upgraderaddr) public returns(bool); /// getter of proposalperiod. /// exception uninitializationexception uninitialized contract. /// exception getterpermissionexception msg.sender is not permitted to call the getter. /// @return this.proposalperiod. function getproposalperiod () public view isready allowedaddress returns(uint256); /// setter of proposalperiod. /// @param _proposalperiod new value of this.proposalperiod. /// exception uninitializationexception uninitialized contract. /// exception permissionexception msg.sender is not the owner. /// @return if this.proposalperiod is successfully set. function setproposalperiod (uint256 _proposalperiod) public isready returns(bool); /// return upgrading status for upgrader contracts. /// @param _originalhandleraddr address of the original handler contract. /// exception uninitializationexception uninitialized contract. /// @return handler contract's upgrading status. function canbeupgraded (address _originalhandleraddr) external view isready returns(upgradingstatus); /// check if the contract has been initialized. /// @return if the contract has been initialized. function live () external view returns(bool); /** getters and setters of data resources: define functions here */ } upgrader contract (optional) handler contract can be upgraded by calling sethandler() of data contract. if the owner wants to collect ideas from users, an upgrader contract will help him/her manage voting and upgrading. below is the specification of upgrader contract: the upgrader contract has the ability to take votes from the registered voters. the contract owner is able to add voters any time before the proposal expires; voter can check the current status of the proposal (succeed or expired). developers are able to delete this upgrader contract by calling done() any time after deployment. the upgrader contract works as follows: verify the data contract, its corresponding handler contract and the new handler contract have all been deployed; deploy an upgrader contract using data contract address, previous handler contract address and new handler contract address; register upgrader address in the new handler contract first, then the original handler and finally the data contract; call startproposal() to start the voting process; call getresolution() before the expiration; upgrading succeed or proposal is expired. note: function done() can be called at any time to let upgrader destruct itself. function status() can be called at any time to show caller status of the upgrader. /// handler upgrader contract upgrader { // data contract datacontract public data; // original handler contract ihandler public originalhandler; // new handler contract address public newhandleraddr; /** marker */ enum upgraderstatus { preparing, voting, success, expired, end } upgraderstatus public status; /// check if the proposal is expired. /// if so, contract would be marked as expired. /// exception preparingupgraderexception proposal has not been started. /// exception reupgradingexception upgrading has been done. /// exception expirationexception proposal is expired. modifier notexpired { require(status != upgraderstatus.preparing, "invalid proposal!"); require(status != upgraderstatus.success, "upgrading has been done!"); require(status != upgraderstatus.expired, "proposal is expired!"); if (data.canbeupgraded(address(originalhandler)) != datacontract.upgradingstatus.inprogress) { status = upgraderstatus.expired; require(false, "proposal is expired!"); } _; } /// start voting. /// upgrader must do upgrading check, namely checking if data contract and 2 handler contracts are ok. /// exception restartingexception proposal has been already started. /// exception permissionexception msg.sender is not the owner. /// exception upgraderconflictexception another upgrader is working. /// exception nopreparationexception original or new handler contract is not prepared. function startproposal () external; /// anyone can try to get resolution. /// if voters get consensus, upgrade the handler contract. /// if expired, self-destruct. /// otherwise, do nothing. /// exception preparingupgraderexception proposal has not been started. /// exception expirationexception proposal is expired. /// @return status of proposal. function getresolution() external returns(upgraderstatus); /// destruct itself. /// exception permissionexception msg.sender is not the owner. function done() external; /** other voting mechanism related variables and functions */ } caveats since the upgrader contract in erc-1504 has a simple voting mechanism, it is prone to all the limitations that the voting contract is facing: the administrator can only be the owner of data and handler contracts. furthermore, only the administrator has the power to add voters and start a proposal. it requires voters to be constantly active, informative and attentive to make a upgrader succeed. the voting will only be valid in a given time period. if in a given time period the contract cannot collect enough “yes” to proceed, the proposal will be marked expired. rationale data contract and handler contract a smart contract is actually a kind of software, which provides some kind of services. from the perspective of software engineering, a service consists of resources that abstract the data and operations that abstract the process logic on the data. the requirement of upgrading is mostly on the logic part. therefore, in order to make a smart contract upgradable, we divide it into two parts: data contract keeps the resources; handler contract contains operations. the handler contract can be upgraded in the future while the data contract is permanent. handler contract can manipulate the variables in data contract through the getter and setter functions provided by data contract. upgrader contract and voting mechanism in order to prevent centralization and protect the interests of the community and stakeholders, we also design a voting mechanism in the upgrader contract. upgrader contract contains addresses of data contract and two handler contracts, and collects votes from pre-defined voters to upgrade the handler contract when the pre-set condition is fulfilled. for simplicity, the upgradable contract comes with a very minimal version of the voting mechanism. if the contract owner wants to implement a more complex voting mechanism, he/she can modify the existing voting mechanism to incorporate upgradability. the expiration mechanism (see modifier notexpried in upgrader contract and related functions in data contract) and upgrading check (see function startproposal() in upgrader contract) to the contract are mandatory. gas and complexity (regarding the enumeration extension) using an upgrader will cost some gas. if the handler contract is upgraded by the owner, it just costs gas that a contract call will cost, which is usually significantly lower than creating and deploying a new contract. although upgrading contract may take some efforts and gas, it is a much less painful than deprecating the insecure contract/creating a new contract or hard fork (e.g. dao attack). contract creation requires a significant amount of effort and gas. one of the advantages of upgradable contracts is that the contract owners don’t have to create new contracts; instead, they only need to upgrade parts of contract that cause issues, which is less expensive compared to data loss and blockchain inconsistency. in other words, upgradable contracts make data contract more scalable and flexible. community consensus thank you to those who helped on review and revise the proposal: @lsankar4033 from mit more the proposal is initiated and developed by the team renaissance and the research group of blockchain system @ center for operating system at peking university. we have been very inclusive in this process and invite anyone with questions or contributions into our discussion. however, this standard is written only to support the identified use cases which are listed herein. implementations renaissance a protocol that connect creators and fans financially erc-1504 a reference implementation copyright copyright and related rights waived via cc0. citation please cite this document as: kaidong wu , chuqiao ren , ruthia he , yun ma , xuanzhe liu , "erc-1504: upgradable smart contract [draft]," ethereum improvement proposals, no. 1504, october 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1504. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1240: remove difficulty bomb ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-1240: remove difficulty bomb authors micah zoltu (@micahzoltu) created 2018-07-21 discussion link https://ethereum-magicians.org/t/difficulty-bomb-removal/832 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementations copyright simple summary the average block times are increasing due to the difficulty bomb (also known as the “ice age”) slowly accelerating. this eip proposes to remove the difficulty increase over time and replace it with a fixed difficulty targeting 15 second blocks. abstract starting with fork_block_number the client will calculate the difficulty without considering the current block number. motivation the difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves. in reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use. if 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants. another way to put this is that miners will follow economic participants, not the other way around. specification remove difficulty for the purposes of calc_difficulty, if block.number >= fork_block_number then change the epsilon component to 0 rather than having it be a function of block number. rationale with the difficulty bomb removed, when casper is released it will be up to economic participants to decide whether they want the features that casper enables or not. if they do not want casper, they are free to continue running unpatched clients and participating in the ethereum network as it exists today. this freedom of choice is the cornerstone of dlts and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice. if the development team is not confident that economic participants will want casper, then they should re-evaluate their priorities rather than trying to force casper onto users. author personal note: i think we will see almost all economic participants in ethereum switch to pos/sharding without any extra pressure beyond client defaults. backwards compatibility this eip is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. therefore, it should be included in a scheduled hardfork at a certain block number. test cases test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. implementations the yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710 copyright copyright and related rights waived via cc0. citation please cite this document as: micah zoltu (@micahzoltu), "eip-1240: remove difficulty bomb [draft]," ethereum improvement proposals, no. 1240, july 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1240. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2294: explicit bound to chain id size ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-2294: explicit bound to chain id size adds a maximum value to the chain id parameter to avoid potential encoding issues that may occur when using large values of the parameter. authors zainan victor zhou (@xinbenlv), alex beregszaszi (@axic) created 2019-09-19 discussion link https://ethereum-magicians.org/t/eip-2294-explicit-bound-to-chain-id/11090 requires eip-155 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract starting from blocknum = fork_blknum, this eip restricts the size of the eip-155 chain id parameter to a particular maximum value floor(max_uint64 / 2) 36, in order to ensure that there is a standard around how this parameter is to be used between different projects. motivation eip-155 introduces the chain id parameter, which is an important parameter used for domain separation (replay protection) of ethereum protocol signed messages. however, it does not specify any properties about the size that this parameter takes. allowing it to be 256-bit wide means that the rlp encoding of a transaction must use >256-bit arithmetic to calculate the v field. and suggests a reasonable maximum enforced size in order to ensure that there are no issues when encoding this parameter. this would allow a sufficient amount of different values for this parameter, which is typically chosen by community consensus as a genesis parameter for a given chain and thus does not change often. without a well-chosen value of chain id, there could be differences in the implementation of eip-155 (and eip-1344 by derivative) in both client codebase and external tooling that could lead to consensus-critical vulnerabilities being introduced to the network. by making this limit explicit, we avoid this scenario for ethereum and any project which uses the ethereum codebase. there have been suggestions of using a hash-based identifier in place on chain id to allow the value to adapt over time to different contentious forks and other scenarios. this proposal does not describe this behavior, but ~63 bits of entropy should be enough to ensure that no collisions are likely for reasonable (e.g. non-malicious) uses of this feature for that purpose. also, the field chainid have experienced increasing usage and dependencies, due more and more contracts are depending on eip-1344 to expose chain id in the smart contract execution. for example when used with eip-712, eip-1271 for on-contract signature verification, chainid has been increasingly introduced for replay attack prevention. it’s security critical to ensure clients depending on the chainid computation in cryptography yields identical result for verification in all cases. originally, this eip was created by bryant eisenbach (@fubuloubu) and alex beregszaszi (@axic). specification starting from blocknum = fork_blknum, the maximum value of chain id is 9,223,372,036,854,775,771 (max_chain_id). compliant client must reject a value outside of the range of [0, max_chain_id] in a provided transaction starting from blocknum = fork_blknum compliant client must disallow a genesis configuration with a value for chain id outside of this limit. due to how the calculation for chain id is performed, the maximum value seen during the arithmetic is chain_id * 2 + 36, so clients must test to ensure no overflow conditions are encountered when the highest value is used. no underflow is possible. rationale the max_chain_id is calculated to avoid overflow when performing uint64 math. for reference, a value of 0 or less is also disallowed. backwards compatibility this eip introduces a change that affects previous implementations of this feature. however, as of time of writing(2022-10-18) no known chain makes use of a value outside of the suggested bounds, there should not be an issue in adopting this limit on the size of this parameter, therefore the impact should be non-existent. if any other chain is operating with a incompatible chainid, we advised they make proper arrangement when this eip becomes adopted. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: zainan victor zhou (@xinbenlv), alex beregszaszi (@axic), "eip-2294: explicit bound to chain id size [draft]," ethereum improvement proposals, no. 2294, september 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2294. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-4834: hierarchical domains ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-4834: hierarchical domains extremely generic name resolution authors gavin john (@pandapip1) created 2022-02-22 table of contents abstract motivation specification contract interface name resolution optional extension: registerable optional extension: enumerable optional extension: access control rationale backwards compatibility security considerations malicious canmovesubdomain (black hole) parent domain resolution copyright abstract this is a standard for generic name resolution with arbitrarily complex access control and resolution. it permits a contract that implements this eip (referred to as a “domain” hereafter) to be addressable with a more human-friendly name, with a similar purpose to erc-137 (also known as “ens”). motivation the advantage of this eip over existing standards is that it provides a minimal interface that supports name resolution, adds standardized access control, and has a simple architecture. ens, although useful, has a comparatively complex architecture and does not have standard access control. in addition, all domains (including subdomains, tlds, and even the root itself) are actually implemented as domains, meaning that name resolution is a simple iterative algorithm, not unlike dns itself. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. contract interface interface idomain { /// @notice query if a domain has a subdomain with a given name /// @param name the subdomain to query, in right to left order /// @return `true` if the domain has a subdomain with the given name, `false` otherwise function hasdomain(string[] memory name) external view returns (bool); /// @notice fetch the subdomain with a given name /// @dev this should revert if `hasdomain(name)` is `false` /// @param name the subdomain to fetch, in right to left order /// @return the subdomain with the given name function getdomain(string[] memory name) external view returns (address); } name resolution to resolve a name (like "a.b.c"), split it by the delimiter (resulting in something like ["a", "b", "c"]). set domain initially to the root domain, and path to be an empty list. pop off the last element of the array ("c") and add it to the path, then call domain.hasdomain(path). if it’s false, then the domain resolution fails. otherwise, set the domain to domain.getdomain(path). repeat until the list of split segments is empty. there is no limit to the amount of nesting that is possible. for example, 0.1.2.3.4.5.6.7.8.9.a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.r.s.t.u.v.w.x.y.z would be valid if the root contains z, and z contains y, and so on. here is a solidity function that resolves a name: function resolve(string[] calldata splitname, idomain root) public view returns (address) { idomain current = root; string[] memory path = []; for (uint i = splitname.length 1; i >= 0; i--) { // append to back of list path.push(splitname[i]); // require that the current domain has a domain require(current.hasdomain(path), "name resolution failed"); // resolve subdomain current = current.getdomain(path); } return current; } optional extension: registerable interface idomainregisterable is idomain { //// events /// @notice must be emitted when a new subdomain is created (e.g. through `createdomain`) /// @param sender msg.sender for createdomain /// @param name name for createdomain /// @param subdomain subdomain in createdomain event subdomaincreate(address indexed sender, string name, address subdomain); /// @notice must be emitted when the resolved address for a domain is changed (e.g. with `setdomain`) /// @param sender msg.sender for setdomain /// @param name name for setdomain /// @param subdomain subdomain in setdomain /// @param oldsubdomain the old subdomain event subdomainupdate(address indexed sender, string name, address subdomain, address oldsubdomain); /// @notice must be emitted when a domain is unmapped (e.g. with `deletedomain`) /// @param sender msg.sender for deletedomain /// @param name name for deletedomain /// @param subdomain the old subdomain event subdomaindelete(address indexed sender, string name, address subdomain); //// crud /// @notice create a subdomain with a given name /// @dev this should revert if `cancreatedomain(msg.sender, name, pointer)` is `false` or if the domain exists /// @param name the subdomain name to be created /// @param subdomain the subdomain to create function createdomain(string memory name, address subdomain) external payable; /// @notice update a subdomain with a given name /// @dev this should revert if `cansetdomain(msg.sender, name, pointer)` is `false` of if the domain doesn't exist /// @param name the subdomain name to be updated /// @param subdomain the subdomain to set function setdomain(string memory name, address subdomain) external; /// @notice delete the subdomain with a given name /// @dev this should revert if the domain doesn't exist or if `candeletedomain(msg.sender, name)` is `false` /// @param name the subdomain to delete function deletedomain(string memory name) external; //// parent domain access control /// @notice get if an account can create a subdomain with a given name /// @dev this must return `false` if `hasdomain(name)` is `true`. /// @param updater the account that may or may not be able to create/update a subdomain /// @param name the subdomain name that would be created/updated /// @param subdomain the subdomain that would be set /// @return whether an account can update or create the subdomain function cancreatedomain(address updater, string memory name, address subdomain) external view returns (bool); /// @notice get if an account can update or create a subdomain with a given name /// @dev this must return `false` if `hasdomain(name)` is `false`. /// if `getdomain(name)` is also a domain implementing the subdomain access control extension, this should return `false` if `getdomain(name).canmovesubdomain(msg.sender, this, subdomain)` is `false`. /// @param updater the account that may or may not be able to create/update a subdomain /// @param name the subdomain name that would be created/updated /// @param subdomain the subdomain that would be set /// @return whether an account can update or create the subdomain function cansetdomain(address updater, string memory name, address subdomain) external view returns (bool); /// @notice get if an account can delete the subdomain with a given name /// @dev this must return `false` if `hasdomain(name)` is `false`. /// if `getdomain(name)` is a domain implementing the subdomain access control extension, this should return `false` if `getdomain(name).candeletesubdomain(msg.sender, this, subdomain)` is `false`. /// @param updater the account that may or may not be able to delete a subdomain /// @param name the subdomain to delete /// @return whether an account can delete the subdomain function candeletedomain(address updater, string memory name) external view returns (bool); } optional extension: enumerable interface idomainenumerable is idomain { /// @notice query all subdomains. must revert if the number of domains is unknown or infinite. /// @return the subdomain with the given index. function subdomainbyindex(uint256 index) external view returns (string memory); /// @notice get the total number of subdomains. must revert if the number of domains is unknown or infinite. /// @return the total number of subdomains. function totalsubdomains() external view returns (uint256); } optional extension: access control interface idomainaccesscontrol is idomain { /// @notice get if an account can move the subdomain away from the current domain /// @dev may be called by `cansetdomain` of the parent domain implement access control here!!! /// @param updater the account that may be moving the subdomain /// @param name the subdomain name /// @param parent the parent domain /// @param newsubdomain the domain that will be set next /// @return whether an account can update the subdomain function canmovesubdomain(address updater, string memory name, idomain parent, address newsubdomain) external view returns (bool); /// @notice get if an account can unset this domain as a subdomain /// @dev may be called by `candeletedomain` of the parent domain implement access control here!!! /// @param updater the account that may or may not be able to delete a subdomain /// @param name the subdomain to delete /// @param parent the parent domain /// @return whether an account can delete the subdomain function candeletesubdomain(address updater, string memory name, idomain parent) external view returns (bool); } rationale this eip’s goal, as mentioned in the abstract, is to have a simple interface for resolving names. here are a few design decisions and why they were made: name resolution algorithm unlike ens’s resolution algorithm, this eip’s name resolution is fully under the control of the contracts along the resolution path. this behavior is more intuitive to users. this behavior allows for greater flexibility e.g. a contract that changes what it resolves to based on the time of day. parent domain access control a simple “ownable” interface was not used because this specification was designed to be as generic as possible. if an ownable implementation is desired, it can be implemented. this also gives parent domains the ability to call subdomains’ access control methods so that subdomains, too, can choose whatever access control mechanism they desire subdomain access control these methods are included so that subdomains aren’t always limited to their parent domain’s access control the root domain can be controlled by a dao with a non-transferable token with equal shares, a tld can be controlled by a dao with a token representing stake, a domain of that tld can be controlled by a single owner, a subdomain of that domain can be controlled by a single owner linked to an nft, and so on. subdomain access control functions are suggestions: an ownable domain might implement an owner override, so that perhaps subdomains might be recovered if the keys are lost. backwards compatibility this eip is general enough to support ens, but ens is not general enough to support this eip. security considerations malicious canmovesubdomain (black hole) description: malicious canmovesubdomain moving a subdomain using setdomain is a potentially dangerous operation. depending on the parent domain’s implementation, if a malicious new subdomain unexpectedly returns false on canmovesubdomain, that subdomain can effectively lock the ownership of the domain. alternatively, it might return true when it isn’t expected (i.e. a backdoor), allowing the contract owner to take over the domain. mitigation: malicious canmovesubdomain clients should help by warning if canmovesubdomain or candeletesubdomain for the new subdomain changes to false. it is important to note, however, that since these are functions, it is possible for the value to change depending on whether or not it has already been linked. it is also still possible for it to unexpectedly return true. it is therefore recommended to always audit the new subdomain’s source code before calling setdomain. parent domain resolution description: parent domain resolution parent domains have full control of name resolution for their subdomains. if a particular domain is linked to a.b.c, then b.c can, depending on its code, set a.b.c to any domain, and c can set b.c itself to any domain. mitigation: parent domain resolution before acquiring a domain that has been pre-linked, it is recommended to always have the contract and all the parents up to the root audited. copyright copyright and related rights waived via cc0. citation please cite this document as: gavin john (@pandapip1), "erc-4834: hierarchical domains," ethereum improvement proposals, no. 4834, february 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-4834. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-649: metropolis difficulty bomb delay and block reward reduction ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-649: metropolis difficulty bomb delay and block reward reduction authors afri schoedon (@5chdn), vitalik buterin (@vbuterin) created 2017-06-21 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary the average block times are increasing due to the difficulty bomb (also known as the “ice age”) slowly accelerating. this eip proposes to delay the difficulty bomb for approximately one and a half year and to reduce the block rewards with the byzantium fork, the first part of the metropolis fork. abstract starting with byzantium_fork_blknum the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 3 million blocks later than previously specified with the homestead fork. furthermore, block rewards will be adjusted to a base of 3 eth, uncle and nephew rewards will be adjusted accordingly. motivation the casper development and switch to proof-of-stake is delayed, the ethash proof-of-work should be feasible for miners and allow sealing new blocks every 15 seconds on average for another one and a half years. with the delay of the ice age, there is a desire to not suddenly also increase miner rewards. the difficulty bomb has been known about for a long time and now it’s going to stop from happening. in order to maintain stability of the system, a block reward reduction that offsets the ice age delay would leave the system in the same general state as before. reducing the reward also decreases the likelihood of a miner driven chain split as ethereum approaches proof-of-stake. specification relax difficulty with fake block number for the purposes of calc_difficulty, simply replace the use of block.number, as used in the exponential ice age component, with the formula: fake_block_number = max(0, block.number 3_000_000) if block.number >= byzantium_fork_blknum else block.number adjust block, uncle, and nephew rewards to ensure a constant ether issuance, adjust the block reward to new_block_reward, where new_block_reward = 3_000_000_000_000_000_000 if block.number >= byzantium_fork_blknum else block.reward (3e18 wei, or 3,000,000,000,000,000,000 wei, or 3 eth). analogue, if an uncle is included in a block for block.number >= byzantium_fork_blknum such that block.number uncle.number = k, the uncle reward is new_uncle_reward = (8 k) * new_block_reward / 8 this is the existing pre-metropolis formula for uncle rewards, simply adjusted with new_block_reward. the nephew reward for block.number >= byzantium_fork_blknum is new_nephew_reward = new_block_reward / 32 this is the existing pre-metropolis formula for nephew rewards, simply adjusted with new_block_reward. rationale this will delay the ice age by 42 million seconds (approximately 1.4 years), so the chain would be back at 30 second block times at the end of 2018. an alternate proposal was to add special rules to the difficulty calculation to effectively pause the difficulty between different blocks. this would lead to similar results. this was previously discussed at all core devs meeting #09, #12, #13, and #14. consensus on the specification was achieved in all core devs meeting #19 and specification drafted in eip issue #649. it was decided to replace eip #186 and include the block reward reduction along with the difficulty bomb delay in all core devs meeting #20 and #21; accepted in #22. backwards compatibility this eip is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. therefore, it should be included in a scheduled hardfork at a certain block number. it’s suggested to include this eip in the first of the two metropolis hard-forks, the byzantium fork. test cases test cases exist in ethereum/tests #269. implementation the following clients implemented eip-649: geth #15028 parity #5855 ethereumj #927 cpp-ethereum #4050 pyethereum #383 the yellow paper implements eip-649 in #333. other notable implementations: eth-isabelle #459 py-evm #123 copyright copyright and related rights waived via cc0. citation please cite this document as: afri schoedon (@5chdn), vitalik buterin (@vbuterin), "eip-649: metropolis difficulty bomb delay and block reward reduction," ethereum improvement proposals, no. 649, june 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-649. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5615: erc-1155 supply extension ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-5615: erc-1155 supply extension a simple mechanism to fetch token supply data from erc-1155 tokens authors gavin john (@pandapip1) created 2023-05-25 requires eip-1155 table of contents abstract specification rationale backwards compatibility security considerations copyright abstract this erc standardizes an existing mechanism to fetch token supply data from erc-1155 tokens. it adds a totalsupply function, which fetches the number of tokens with a given id, and an exists function, which checks for the existence of a given id. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. interface erc1155supply is erc1155 { // @notice this function must return whether the given token id exists, previously existed, or may exist // @param id the token id of which to check the existence // @return whether the given token id exists, previously existed, or may exist function exists(uint256 id) external view returns (bool); // @notice this function must return the number of tokens with a given id. if the token id does not exist, it must return 0. // @param id the token id of which fetch the total supply // @return the total supply of the given token id function totalsupply(uint256 id) external view returns (uint256); } implementations may support erc-165 interface discovery, but consumers must not rely on it. rationale this erc does not implement erc-165, as this interface is simple enough that the extra complexity is unnecessary and would cause incompatibilities with pre-existing implementations. the totalsupply and exists functions were modeled after erc-721 and erc-20. totalsupply does not revert if the token id does not exist, since contracts that care about that case should use exists instead (which might return false even if totalsupply is zero). exists is included to differentiate between the two ways that totalsupply could equal zero (either no tokens with the given id have been minted yet, or no tokens with the given id will ever be minted). backwards compatibility this erc is designed to be backward compatible with the openzeppelin erc1155supply. security considerations none. copyright copyright and related rights waived via cc0. citation please cite this document as: gavin john (@pandapip1), "erc-5615: erc-1155 supply extension," ethereum improvement proposals, no. 5615, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-5615. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1948: non-fungible data token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1948: non-fungible data token authors johann barbie (@johannbarbie), ben bollen , pinkiebell (@pinkiebell) created 2019-04-18 discussion link https://ethereum-magicians.org/t/erc-non-fungible-data-token/3139 requires eip-721 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary some nft use-cases require to have dynamic data associated with a non-fungible token that can change during its lifetime. examples for dynamic data: cryptokitties that can change color intellectual property tokens that encode rights holders tokens that store data to transport them across chains the existing metadata standard does not suffice as data can only be set at minting time and not modified later. abstract non-fungible tokens (nfts) are extended with the ability to store dynamic data. a 32 bytes data field is added and a read function allows to access it. the write function allows to update it, if the caller is the owner of the token. an event is emitted every time the data updates and the previous and new value is emitted in it. motivation the proposal is made to standardize on tokens with dynamic data. interactions with bridges for side-chains like xdai or plasma chains will profit from the ability to use such tokens. protocols that build on data tokens like distributed breeding will be enabled. specification an extension of erc-721 interface with the following functions and events is suggested: pragma solidity ^0.5.2; /** * @dev interface of the erc1948 contract. */ interface ierc1948 { /** * @dev emitted when `olddata` is replaced with `newdata` in storage of `tokenid`. * * note that `olddata` or `newdata` may be empty bytes. */ event dataupdated(uint256 indexed tokenid, bytes32 olddata, bytes32 newdata); /** * @dev reads the data of a specified token. returns the current data in * storage of `tokenid`. * * @param tokenid the token to read the data off. * * @return a bytes32 representing the current data stored in the token. */ function readdata(uint256 tokenid) external view returns (bytes32); /** * @dev updates the data of a specified token. writes `newdata` into storage * of `tokenid`. * * @param tokenid the token to write data to. * @param newdata the data to be written to the token. * * emits a `dataupdated` event. */ function writedata(uint256 tokenid, bytes32 newdata) external; } rationale the suggested data field in the nft is used either for storing data directly, like a counter or address. if more data is required the implementer should fall back to authenticated data structures, like merkleor patricia-trees. the proposal for this erc stems from the distributed breeding proposal to allow better integration of nfts across side-chains. ost.com, skale, poa, and leapdao have been part of the discussion. backwards compatibility 🤷‍♂️ no related proposals are known to the author, hence no backwards compatibility to consider. test cases simple happy test: const erc1948 = artifacts.require('./erc1948.sol'); contract('erc1948', (accounts) => { const firsttokenid = 100; const empty = '0x0000000000000000000000000000000000000000000000000000000000000000'; const data = '0x0101010101010101010101010101010101010101010101010101010101010101'; let datatoken; beforeeach(async () => { datatoken = await erc1948.new(); await datatoken.mint(accounts[0], firsttokenid); }); it('should allow to write and read', async () => { let rsp = await datatoken.readdata(firsttokenid); assert.equal(rsp, empty); await datatoken.writedata(firsttokenid, data); rsp = await datatoken.readdata(firsttokenid); assert.equal(rsp, data); }); }); implementation an example implementation of the interface in solidity would look like this: /** * @dev implementation of erc721 token and the `ierc1948` interface. * * erc1948 is a non-fungible token (nft) extended with the ability to store * dynamic data. the data is a bytes32 field for each tokenid. if 32 bytes * do not suffice to store the data, an authenticated data structure (hash or * merkle tree) shall be used. */ contract erc1948 is ierc1948, erc721 { mapping(uint256 => bytes32) data; /** * @dev see `ierc1948.readdata`. * * requirements: * * `tokenid` needs to exist. */ function readdata(uint256 tokenid) external view returns (bytes32) { require(_exists(tokenid)); return data[tokenid]; } /** * @dev see `ierc1948.writedata`. * * requirements: * * `msg.sender` needs to be owner of `tokenid`. */ function writedata(uint256 tokenid, bytes32 newdata) external { require(msg.sender == ownerof(tokenid)); emit dataupdated(tokenid, data[tokenid], newdata); data[tokenid] = newdata; } } copyright copyright and related rights waived via cc0. citation please cite this document as: johann barbie (@johannbarbie), ben bollen , pinkiebell (@pinkiebell), "erc-1948: non-fungible data token [draft]," ethereum improvement proposals, no. 1948, april 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1948. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5437: security contact interface ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5437: security contact interface an interface for security notice using asymmetric encryption authors zainan zhou (@xinbenlv) created 2022-08-09 discussion link https://ethereum-magicians.org/t/erc-interface-for-security-contract/10303 requires eip-165 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract an interface for security notice using asymmetric encryption. the interface exposes a asymmetric encryption key and a destination of delivery. motivation currently there is no consistent way to specify an official channel for security researchers to report security issues to smart contract maintainers. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. interface ieip5437 { /// required function getsecuritycontact(uint8 type, bytes memory data) public view returns ( uint8 type, bytes memory publickey, bytes memory extradata ); /// optional // todo consider remove if not needed before finalized function setsecuritycontact( uint8 type, bytes memory publickey, bytes memory extradata) public; event securitycontactchanged(uint8 type, bytes memory publickeyforencryption, bytes memory extradata); /// optional function securitynotify(uint8 type, bytes memory data) public payable; /// optional event onsecuritynotification(uint8 type, bytes memory sourcedata, uint256 value); /// optional // todo consider to make it a separate eip function bountypolicy(uint256 id) public view returns(string, bytes memory extradata); } compliant interfaces must implement the getsecuritycontact method. type is a one byte data with valid range of [0x10, 0x7f]. the ranges of [0x00, 0x0f] and [0x80, 0xff] are reserved for future extension. the type indicates the format of the publickey and extradata in the following way | type | encryption scheme | extradata | ——-|————————————-|————————————————– | 0x10 | gnupg rsa/3072 | email address(es) encoded in format of rfc 2822 | ———————————————————————————————— a new version of this table can be proposed by future eips by specifying a new type number. the publickey returned from getsecuritycontact must follow the encryption scheme specified in the table above. the following is an example of a publickey using rsa/3072 generated via gnupg in an rfc 20 ascii-encoding of the public key string: -----begin pgp public key block----mqgnbglzm2ybdadncxaw/a0idvkneq6s/iyueiie+2mwmhcbgqli0zrfz7pkwi+d m6hek51sg2c7zlswpep8kqanrj/cv1stxhf+kaztyefiaqpizl1wtb6qgkywgsjf sxjbu3dulzlut2yvtfbezswavreadjlxywdpboorhvfte2vovi6igcjdh7pw7w7g igzll6uklgg7y9fuo2dsmjcr/twmlcupnddln2cuhnfenhz34fmd61nxchlc7cik p8xkft8gcxurnitjqi5hab8bgfr34kflvpr2+ikd5e+vqxcwk7vb443nruvf8osn uddf8z6mgl7bkbbgyyh58qsvlmz8g3e4yamkjpwozek3v2r8yh4etdr670zcrriz qwvkibggmq3j/9ryps5hfqpj4wv60bsh1xuijeias3ubmt7z5jyfeze7vlxglwot p+snafkzlzt4cdel2leedrbpnpoedp0x9hyseaxtxbgsptdaxp2myhw3u6pyeehg od0uvtljwgu+6akaeqeaabqjc29tzxjlywxuyw1lidxncgcubg9jywwuz2vuqhp6 bi5pbt6jadqeeweiad4wiqtdk/9jzrz+lu2cy8rsvjnbud1lrqucyvmzzgibawuj eswdaaulcqghagyvcgkicwiefgidaqieaqixgaakcrdsvjnbud1lrauldacqfbqg e9hfok17ucpvz/u4znwmfd9zfawsykgqrk9xmvz0r8pr7y3dp5hfvaptqid/lhha 2opez1viiydbcqg9wowjcoynoioseaczrvf8ytuc2mhi+5ddyhtst74jdluwmw3u abbxhds3kcry5/j01kqqi4uwsmbcyyh3jl3iwjkgy0kdbbuqakvahpmnnt81ayvz ucdsnb9n/jmdxuwnccysr+cllw4mk68pdiuk5qw0jmaoujhfowsgmtbfslav/lre qu8mnrlss5ipvvaj3udouyrob2fsbvwxayfaavs1izf2vqfbjpndwddyopnymjlp s2sfu02mvrgp3wanbtvm52up42sllnjbquvjv03/qwfxcrejgajobn+iaoxp9noe qfqdkzypba9fohdkl9991n21xbzczzagf9ryu9izapanwzyex1zfzjsup/hrjhp8 ljs8micjilmplk66tmjte4dn5eml1bpohmfmx8k0ileslsuhxeg1jbnyidk5ay0e yvmzzgemalnikonpqckv+yap8tb8tbjmm+3tiojqroviinuqzh6lzm3/m+dpxawz r0mih1a3+o+thlz70tls67w3sjd62swafzalzw4f+gtqjbth6lurdqdv8oxurgga skk222adp+fr21h/ttpleydvcgm8xvi4cy7jmf5cft5jdio7a+fyfbnltfsvqzlm tgfokufbg8kjkvdjwirs2fctkelwz8+ilq52ybrxwbdar843x1frmsy+x9nnugup ryn1u4jbptu2pekg5q94jzuztkgzhczbjy7a8mtvs0mlqie0se1p+hfly76rma/f hb6j4jnotzbz0/1fvvuocmkjuz2dx81qocz8np6eafzkvnyzrga5njnjwo1ag5jq d8qhuowxs8fy9evmkwavl51evlfnt532i4lk0zhsbf8mcczjpefmskwalkjn02ml ytd+ljylf8skmolvps8kc4vymr1lz0pwspkdfomkc1lrurpm7uttck+/rfg1olyq skbmdi37kqaraqabiqg8bbgbcaamfieew5p/y80wfpvnngpk0lstw7ndza0famlz m2ycgwwfcrlmawaacgkq0lstw7ndza2ofgv8daxhtrzchtvjxtdlhqeusht80jcq zghd7oui9eu3k+odj9aktkzf1fqmlqooskgbsly/xpwwyhatv2onlthsjydkz7qs jsxshqpuvj3x00yn9pxg1z1jkl7rzy2/0dnq8afp+gktfu2oat4uiu4ysqrsvw/z sbdtsw3t4e6uf0qukdf49mk3y2nhtwy0yzqjnuqksuuvpum5a/4zsoairz+vsnjx moxuik/f8unwabpm90ocpttmtzxcc1uxehtnm6ibjthfiq3gelzh+gniola5klo1 +ybsfechlflz27pwgfibyppvsuqmrhef+j3g6sxybowdhvyr3za1fzxqvibwoiee ndkg0bu7zai2b/c8uh/wht5ivtfzhlestjdqg8uyltnadxhqzie9jizwsq1dsonc yru7cqtl+/hrpigfhfclaxln8vwkjnuvp+fg1zpte1t/skddz7m29hd9nzuc0oqw moa+hdqga3a9kwbqksloorq4unft1eu/fcra =o6bf -----end pgp public key block---- if setsecuritycontact is implemented and a call to it has succeeded in setting a new security contact, an event securitycontactchanged must be emitted with the identical passed-in-parameters of setsecuritycontact it’s also recommended that an on-chain security notify method securitynotify to implemented to receive security notice onchain. if it’s implemented and a call has succeeded, it must emit an onsecuritynotification with identical pass-in-parameter data. compliant interfaces must implement eip-165. it’s recommended to set a bounty policy via bountypolicy method. the id = 0 is preserved for a full overview, while other digits are used for different individual bounty policies. the returned string will be uri to content of bounty policies. no particular format of bounty policy is specified. rationale for simplicity, this eip specifies a simple gpg scheme with a given encryption scheme and uses email addresses as a contact method. it’s possible that future eips will specify new encryption schemes or delivery methods. this eip adds an optional method, setsecuritycontact, to set the security contact, because it might change due to circumstances such as the expiration of the cryptographic keys. this eip explicitly marks securitynotify as payable, in order to allow implementers to set a staking amount to report a security vulnerability. this eip allows for future expansion by adding the bountypolicy the extradata fields. additional values of these fields may be added in future eips. backwards compatibility currently, existing solutions such as openzeppelin use plaintext in source code /// @custom:security-contact some-user@some-domain.com it’s recommend that new versions of smart contracts adopt this eip in addition to the legacy @custom:security-contact approach. security considerations implementors should properly follow security practices required by the encryption scheme to ensure the security of the chosen communication channel. some best practices are as follows: keep security contact information up-to-date; rotate encryption keys in the period recommended by best practice; regularly monitor the channel to receive notices in a timely manner. copyright copyright and related rights waived via cc0. citation please cite this document as: zainan zhou (@xinbenlv), "erc-5437: security contact interface [draft]," ethereum improvement proposals, no. 5437, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5437. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-4396: time-aware base fee calculation ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-4396: time-aware base fee calculation accounts for block time in the base fee calculation to target a stable throughput by time instead of by block. authors ansgar dietrichs (@adietrichs) created 2021-10-28 discussion link https://ethereum-magicians.org/t/eip-4396-time-aware-base-fee-calculation/7363 table of contents abstract motivation base fee volatility under proof-of-work missed slots throughput degradation during consensus issues specification rationale mechanism limitations possible extensions backwards compatibility test cases reference implementation security considerations timestamp manipulation suppressing base fee increases copyright abstract this eip proposes accounting for time between blocks in the base fee calculation to target a stable throughput by time, instead of by block. aiming to minimize changes to the calculation, it only introduces a variable block gas target proportional to the block time. the eip can, in principle, be applied to either a proof-of-work or a proof-of-stake chain, however the security implications for the proof-of-work case remain unexplored. motivation the current base fee calculation chooses the gas usage of a block as the signal to determine whether demand for block space is too low (indicating that the base fee should be lowered) or too high (indicating that the base fee should be increased). while simple, this choice of signal has drawbacks: it does not take the block time into account. assuming a relatively constant demand, a proposer constructing a block after 20 seconds will have transactions available with twice the gas of a proposer constructing a block after 10 seconds. using the same gas target for both is accordingly sub-optimal. in practice, there are several undesirable consequences of this flawed signal: base fee volatility under proof-of-work under proof-of-work (pow), block times are stochastic, and for that reason there exists large block time variability. this variability contributes to the base fee volatility, where the base fee can be expected to oscillate around the equilibrium value even under perfectly stable demand. missed slots under proof-of-stake (pos), block times are ideally uniform (always 12s), but missed slots lead to individual blocks with increased block time (24s, 36s, …). such missed slots will result in the next block being overfull, and with the current update rule, signal a fake demand spike and thus cause a small unwarranted base fee spike. more importantly, these missed slots directly reduce the overall throughput of the execution chain by the gas target of one block. while the next block can be expected to include the “delayed” transactions of the missed slot, the resulting base fee spike then results in some number of under-full blocks. in the end the block space of the missed slot is lost for the chain. this is particularly problematic because a denial-of-service (dos) attack on block proposers can cause them to miss slots, and compromises the overall chain performance. throughput degradation during consensus issues a more severe version of individual missed slots can be caused by consensus issues that prevent a significant portion of block proposers from continuing to create blocks. this can be due to block proposers forking off (and creating blocks on their own fork), being unable to keep up with the current chain head for another reason, or simply being unable to create valid blocks. in all these situations, average block times go up significantly, causing chain throughput to fall by the same fraction. while this effect is already present under pow, the self-healing mechanism of difficulty adjustments is relatively quick to kick in and restore normal block times. on the other hand, under pos the automatic self-healing mechanism can be extremely slow: potentially several months to return to normal with up to a third of slots missed, or several weeks if more than a third of slots are missed. for all these reasons, it would be desirable to target a stable throughput per time instead of per block, by taking block time into account during the base fee calculation. to maximize the chance of this eip being included in the merge fork, the adjustments are kept to a minimum, with more involved changes discussed in the rationale section. specification using the pseudocode language of eip-1559, the updated base fee calculation becomes: ... base_fee_max_change_denominator = 8 block_time_target = 12 max_gas_target_percent = 95 class world(abc): def validate_block(self, block: block) -> none: parent_gas_limit = self.parent(block).gas_limit parent_block_time = self.parent(block).timestamp self.parent(self.parent(block)).timestamp parent_base_gas_target = parent_gas_limit // elasticity_multiplier parent_adjusted_gas_target = min(parent_base_gas_target * parent_block_time // block_time_target, parent_gas_limit * max_gas_target_percent // 100) parent_base_fee_per_gas = self.parent(block).base_fee_per_gas parent_gas_used = self.parent(block).gas_used ... if parent_gas_used == parent_adjusted_gas_target: expected_base_fee_per_gas = parent_base_fee_per_gas elif parent_gas_used > parent_adjusted_gas_target: gas_used_delta = parent_gas_used parent_adjusted_gas_target base_fee_per_gas_delta = max(parent_base_fee_per_gas * gas_used_delta // parent_base_gas_target // base_fee_max_change_denominator, 1) expected_base_fee_per_gas = parent_base_fee_per_gas + base_fee_per_gas_delta else: gas_used_delta = parent_adjusted_gas_target parent_gas_used base_fee_per_gas_delta = parent_base_fee_per_gas * gas_used_delta // parent_base_gas_target // base_fee_max_change_denominator expected_base_fee_per_gas = parent_base_fee_per_gas base_fee_per_gas_delta ... ... rationale mechanism the proposed new base fee calculation only adjusts the block gas target by scaling it with the block time, capped at a maximum percent of the overall block gas limit: current base fee calculation proposed base fee calculation this new calculation thus targets a stable throughput per time instead of per block. limitations under pos, block time increases always come in multiples of full blocks (e.g. a single missed slot = 24s instead of 12s block time). accounting for this already requires doubling the block gas target, even for a single missed slot. however, with the block elasticity currently set to 2, this target would be equal to the block gas limit. having the new target equal to the block gas limit is less than ideal, and thus is reduced slightly, according to the max_gas_target_percent parameter. the reason for the existence of this parameter is twofold: ensure that the signal remains meaningful: a target equal to or greater than the gas limit could never be reached, so the base fee would always be reduced after a missed slot. ensure that the base fee can still react to genuine demand increases: during times of many offline block proposers (and thus many missed slots), genuine demand increases still need a way to eventually result in a base fee increase, to avoid a fallback to a first-price priority fee auction. however, this means that even a single missed slot cannot be fully compensated. even worse, any second or further sequential missed slot cannot be compensated for at all, as the gas target is already at its max. this effect becomes more pronounced as the share of offline validators increases: as can be observed, while this eip does indeed increase the robustness of the network throughput in cases of offline validators, it does so imperfectly. furthermore, there is a tradeoff effected by the max_gas_target_percent parameter, with a higher value resulting in a higher network robustness, but a more impaired base fee adjustment mechanism during times of frequent missed slots. possible extensions these limitations directly result from the design goal of a minimal change, to maximize chances of being included in the merge. there are natural ways of extending the eip design to more effectively handle offline validators, at the expense of somewhat more extensive changes: persistent multi-slot buffer to be able to compensate multiple consecutive missed slots, a gas buffer could be introduced, that would allow the gas beyond the block elasticity to be carried forward to future blocks. to avoid long-run buffer accumulation that would delay a return to normal operations once block proposers are back online, a cap on the buffer would be added. even for a relatively small buffer cap, the throughput robustness is significantly improved: with an elasticity still at 2, there is no way of avoiding the eventual breakdown for more than 50% offline block proposers. the main implementation complexity for this approach comes from the introduction of the buffer as a new persistent field. to retain the ability for calculating base fees only based on headers, it would have to be added to the block header. increased block elasticity in addition to the introduction of a buffer, increasing the block elasticity is another tool for increasing throughput robustness. the following diagram shows the effect of different elasticity levels, both in the presence and absence of a persistent buffer: again, a clear positive effect can be observed. the main additional complexity here would come from the increased peak load (networking, compute & disk access) of multiple sequential overfull blocks. note though that pos with its minimum block time of 12s significantly reduces worst case peak stress as compared to pow. backwards compatibility the eip has minimal impact on backwards compatibility, only requiring updates to existing base fee calculation tooling. test cases tbd reference implementation tbd security considerations timestamp manipulation under pow, miners are in control over the timestamp field of their blocks. while there are some enforced limits to valid timestamps, implications regarding potential timestamp manipulation are nontrivial and remain unexplored for this eip. under pos, each slot has a fixed assigned timestamp, rendering any timestamp manipulation by block proposers impossible. suppressing base fee increases as discussed in the rationale, a high value for max_gas_target_percent during times of many offline block proposers results in a small remaining signal space for genuine demand increases that should result in base fee increases. this in turn decreases the cost for block proposers for suppresing these base fee increases, instead forcing the fallback to a first-price priority fee auction. while the arguments of incentive incompatibility for base fee suppression of the the base eip-1559 case still apply here, with a decreasing cost of this individually irrational behavior the risk for overriding psychological factors becomes more significant. even in such a case the system degradation would however be graceful, as it would only temporarily suspend the base fee burn. as soon as the missing block proposers would come back online, the system would return to its ordinary eip-1559 equilibrium. copyright copyright and related rights waived via cc0. citation please cite this document as: ansgar dietrichs (@adietrichs), "eip-4396: time-aware base fee calculation [draft]," ethereum improvement proposals, no. 4396, october 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4396. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5639: delegation registry ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: erc erc-5639: delegation registry delegation of permissions for safer and more convenient signing operations. authors foobar (@0xfoobar), wilkins chung (@wwhchung) , ryley-o (@ryley-o), jake rockland (@jakerockland), andy8052 (@andy8052) created 2022-09-09 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation problems with existing methods and solutions proposal: use of a delegation registry specification checking delegation rationale allowing for vault, contract or token level delegation on-chain enumeration security considerations copyright abstract this eip describes the details of the delegation registry, a proposed protocol and abi definition that provides the ability to link one or more delegate wallets to a vault wallet in a manner which allows the linked delegate wallets to prove control and asset ownership of the vault wallet. motivation proving ownership of an asset to a third party application in the ethereum ecosystem is common. users frequently sign payloads of data to authenticate themselves before gaining access to perform some operation. however, this method–akin to giving the third party root access to one’s main wallet–is both insecure and inconvenient. examples: in order for you to edit your profile on opensea, you must sign a message with your wallet. in order to access nft gated content, you must sign a message with the wallet containing the nft in order to prove ownership. in order to gain access to an event, you must sign a message with the wallet containing a required nft in order to prove ownership. in order to claim an airdrop, you must interact with the smart contract with the qualifying wallet. in order to prove ownership of an nft, you must sign a payload with the wallet that owns that nft. in all the above examples, one interacts with the dapp or smart contract using the wallet itself, which may be inconvenient (if it is controlled via a hardware wallet or a multi-sig) insecure (since the above operations are read-only, but you are signing/interacting via a wallet that has write access) instead, one should be able to approve multiple wallets to authenticate on behalf of a given wallet. problems with existing methods and solutions unfortunately, we’ve seen many cases where users have accidentally signed a malicious payload. the result is almost always a significant loss of assets associated with the delegate address. in addition to this, many users keep significant portions of their assets in ‘cold storage’. with the increased security from ‘cold storage’ solutions, we usually see decreased accessibility because users naturally increase the barriers required to access these wallets. proposal: use of a delegation registry this proposal aims to provide a mechanism which allows a vault wallet to grant wallet, contract or token level permissions to a delegate wallet. this would achieve a safer and more convenient way to sign and authenticate, and provide ‘read only’ access to a vault wallet via one or more secondary wallets. from there, the benefits are twofold. this eip gives users increased security via outsourcing potentially malicious signing operations to wallets that are more accessible (hot wallets), while being able to maintain the intended security assumptions of wallets that are not frequently used for signing operations. improving dapp interaction security many dapps requires one to prove control of a wallet to gain access. at the moment, this means that you must interact with the dapp using the wallet itself. this is a security issue, as malicious dapps or phishing sites can lead to the assets of the wallet being compromised by having them sign malicious payloads. however, this risk would be mitigated if one were to use a secondary wallet for these interactions. malicious interactions would be isolated to the assets held in the secondary wallet, which can be set up to contain little to nothing of value. improving multiple device access security in order for a non-hardware wallet to be used on multiple devices, you must import the seed phrase to each device. each time a seed phrase is entered on a new device, the risk of the wallet being compromised increases as you are increasing the surface area of devices that have knowledge of the seed phrase. instead, each device can have its own unique wallet that is an authorized secondary wallet of the main wallet. if a device specific wallet was ever compromised or lost, you could simply remove the authorization to authenticate. further, wallet authentication can be chained so that a secondary wallet could itself authorize one or many tertiary wallets, which then have signing rights for both the secondary address as well as the root main address. this, can allow teams to each have their own signer while the main wallet can easily invalidate an entire tree, just by revoking rights from the root stem. improving convenience many invididuals use hardware wallets for maximum security. however, this is often inconvenient, since many do not want to carry their hardware wallet with them at all times. instead, if you approve a non-hardware wallet for authentication activities (such as a mobile device), you would be able to use most dapps without the need to have your hardware wallet on hand. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. let: vault represent the vault address we are trying to authenticate or prove asset ownership for. delegate represent the address we want to use for signing in lieu of vault. a delegation registry must implement idelegationregistry /** * @title an immutable registry contract to be deployed as a standalone primitive * @dev new project launches can read previous cold wallet -> hot wallet delegations * from here and integrate those permissions into their flow */ interface idelegationregistry { /// @notice delegation type enum delegationtype { none, all, contract, token } /// @notice info about a single delegation, used for onchain enumeration struct delegationinfo { delegationtype type_; address vault; address delegate; address contract_; uint256 tokenid; } /// @notice info about a single contract-level delegation struct contractdelegation { address contract_; address delegate; } /// @notice info about a single token-level delegation struct tokendelegation { address contract_; uint256 tokenid; address delegate; } /// @notice emitted when a user delegates their entire wallet event delegateforall(address vault, address delegate, bool value); /// @notice emitted when a user delegates a specific contract event delegateforcontract(address vault, address delegate, address contract_, bool value); /// @notice emitted when a user delegates a specific token event delegatefortoken(address vault, address delegate, address contract_, uint256 tokenid, bool value); /// @notice emitted when a user revokes all delegations event revokealldelegates(address vault); /// @notice emitted when a user revoes all delegations for a given delegate event revokedelegate(address vault, address delegate); /** * ---------- write ---------- */ /** * @notice allow the delegate to act on your behalf for all contracts * @param delegate the hotwallet to act on your behalf * @param value whether to enable or disable delegation for this address, true for setting and false for revoking */ function delegateforall(address delegate, bool value) external; /** * @notice allow the delegate to act on your behalf for a specific contract * @param delegate the hotwallet to act on your behalf * @param contract_ the address for the contract you're delegating * @param value whether to enable or disable delegation for this address, true for setting and false for revoking */ function delegateforcontract(address delegate, address contract_, bool value) external; /** * @notice allow the delegate to act on your behalf for a specific token * @param delegate the hotwallet to act on your behalf * @param contract_ the address for the contract you're delegating * @param tokenid the token id for the token you're delegating * @param value whether to enable or disable delegation for this address, true for setting and false for revoking */ function delegatefortoken(address delegate, address contract_, uint256 tokenid, bool value) external; /** * @notice revoke all delegates */ function revokealldelegates() external; /** * @notice revoke a specific delegate for all their permissions * @param delegate the hotwallet to revoke */ function revokedelegate(address delegate) external; /** * @notice remove yourself as a delegate for a specific vault * @param vault the vault which delegated to the msg.sender, and should be removed */ function revokeself(address vault) external; /** * ---------- read ---------- */ /** * @notice returns all active delegations a given delegate is able to claim on behalf of * @param delegate the delegate that you would like to retrieve delegations for * @return info array of delegationinfo structs */ function getdelegationsbydelegate(address delegate) external view returns (delegationinfo[] memory); /** * @notice returns an array of wallet-level delegates for a given vault * @param vault the cold wallet who issued the delegation * @return addresses array of wallet-level delegates for a given vault */ function getdelegatesforall(address vault) external view returns (address[] memory); /** * @notice returns an array of contract-level delegates for a given vault and contract * @param vault the cold wallet who issued the delegation * @param contract_ the address for the contract you're delegating * @return addresses array of contract-level delegates for a given vault and contract */ function getdelegatesforcontract(address vault, address contract_) external view returns (address[] memory); /** * @notice returns an array of contract-level delegates for a given vault's token * @param vault the cold wallet who issued the delegation * @param contract_ the address for the contract holding the token * @param tokenid the token id for the token you're delegating * @return addresses array of contract-level delegates for a given vault's token */ function getdelegatesfortoken(address vault, address contract_, uint256 tokenid) external view returns (address[] memory); /** * @notice returns all contract-level delegations for a given vault * @param vault the cold wallet who issued the delegations * @return delegations array of contractdelegation structs */ function getcontractleveldelegations(address vault) external view returns (contractdelegation[] memory delegations); /** * @notice returns all token-level delegations for a given vault * @param vault the cold wallet who issued the delegations * @return delegations array of tokendelegation structs */ function gettokenleveldelegations(address vault) external view returns (tokendelegation[] memory delegations); /** * @notice returns true if the address is delegated to act on the entire vault * @param delegate the hotwallet to act on your behalf * @param vault the cold wallet who issued the delegation */ function checkdelegateforall(address delegate, address vault) external view returns (bool); /** * @notice returns true if the address is delegated to act on your behalf for a token contract or an entire vault * @param delegate the hotwallet to act on your behalf * @param contract_ the address for the contract you're delegating * @param vault the cold wallet who issued the delegation */ function checkdelegateforcontract(address delegate, address vault, address contract_) external view returns (bool); /** * @notice returns true if the address is delegated to act on your behalf for a specific token, the token's contract or an entire vault * @param delegate the hotwallet to act on your behalf * @param contract_ the address for the contract you're delegating * @param tokenid the token id for the token you're delegating * @param vault the cold wallet who issued the delegation */ function checkdelegatefortoken(address delegate, address vault, address contract_, uint256 tokenid) external view returns (bool); } checking delegation a dapp or smart contract would check whether or not a delegate is authenticated for a vault by checking the return value of checkdelegateforall. a dapp or smart contract would check whether or not a delegate can authenticated for a contract associated with a by checking the return value of checkdelegateforcontract. a dapp or smart contract would check whether or not a delegate can authenticated for a specific token owned by a vault by checking the return value of checkdelegatefortoken. a delegate can act on a token if they have a token level delegation, contract level delegation (for that token’s contract) or vault level delegation. a delegate can act on a contract if they have contract level delegation or vault level delegation. for the purposes of saving gas, it is expected if delegation checks are performed at a smart contract level, the dapp would provide a hint to the smart contract which level of delegation the delegate has so that the smart contract can verify with the delegation registry using the most gas efficient check method. rationale allowing for vault, contract or token level delegation in order to support a wide range of delegation use cases, the proposed specification allows a vault to delegate all assets it controls, assets of a specific contract, or a specific token. this ensures that a vault has fine grained control over the security of their assets, and allows for emergent behavior around granting third party wallets limited access only to assets relevant to them. on-chain enumeration in order to support ease of integration and adoption, this specification has chosen to include on-chain enumeration of delegations and incur the additional gas cost associated with supporting enumeration. on-chain enumeration allows for dapp frontends to identify the delegations that any connected wallet has access to, and can provide ui selectors. without on-chain enumeration, a dapp would require the user to manually input the vault, or would need a way to index all delegate events. security considerations the core purpose of this eip is to enhance security and promote a safer way to authenticate wallet control and asset ownership when the main wallet is not needed and assets held by the main wallet do not need to be moved. consider it a way to do ‘read only’ authentication. copyright copyright and related rights waived via cc0. citation please cite this document as: foobar (@0xfoobar), wilkins chung (@wwhchung) , ryley-o (@ryley-o), jake rockland (@jakerockland), andy8052 (@andy8052), "erc-5639: delegation registry [draft]," ethereum improvement proposals, no. 5639, september 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5639. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. cryptographic code obfuscation: decentralized autonomous organizations are about to take a huge leap forward | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search cryptographic code obfuscation: decentralized autonomous organizations are about to take a huge leap forward posted by vitalik buterin on february 8, 2014 research & development there have been a number of very interesting developments in cryptography in the past few years. satoshi’s blockchain notwithstanding, perhaps the first major breakthrough after blinding and zero-knowledge proofs is fully homomorphic encryption, a technology which allows you to upload your data onto a server in an encrypted form so that the server can then perform calculations on it and send you back the results all without having any idea what the data is. in 2013, we saw the beginnings of succinct computational integrity and privacy (scip), a toolkit pioneered by eli ben sasson in israel that lets you cryptographically prove that you carried out some computation and got a certain output. on the more mundane side, we now have sponge functions, an innovation that substantially simplifies the previous mess of hash functions, stream ciphers and pseudorandom number generators into a beautiful, single construction. most recently of all, however, there has been another major development in the cryptographic scene, and one whose applications are potentially very far-reaching both in the cryptocurrency space and for software as a whole: obfuscation. the idea behind obfuscation is an old one, and cryptographers have been trying to crack the problem for years. the problem behind obfuscation is this: is it possible to somehow encrypt a program to produce another program that does the same thing, but which is completely opaque so there is no way to understand what is going on inside? the most obvious use case is proprietary software – if you have a program that incorporates advanced algorithms, and want to let users use the program on specific inputs without being able to reverse-engineer the algorithm, the only way to do such a thing is to obfuscate the code. proprietary software is for obvious reasons unpopular among the tech community, so the idea has not seen a lot of enthusiasm, a problem compounded by the fact that each and every time a company would try to put an obfuscation scheme into practice it would quickly get broken. five years ago, researchers put what might perhaps seem to be a final nail in the coffin: a mathematical proof, using arguments vaguely similar to those used to show the impossibility of the halting problem, that a general purpose obfuscator that converts any program into a “black box” is impossible. at the same time, however, the cryptography community began to follow a different path. understanding that the “black box” ideal of perfect obfuscation will never be achieved, researchers set out to instead aim for a weaker target: indistinguishability obfuscation. the definition of an indistinguishability obfuscator is this: given two programs a and b that compute the same function, if an effective indistinguishability obfuscator o computes two new programs x=o(a) and y=o(b), given x and y there is no (computationally feasible) way to determine which of x and y came from a and which came from b. in theory, this is the best that anyone can do; if there is a better obfuscator, p, then if you put a and p(a) through the indistinguishability obfuscatoro, there would be no way to tell between o(a) and o(p(a)), meaning that the extra step of adding p could not hide any information about the inner workings of the program that o does not. creating such an obfuscator is the problem which many cryptographers have occupied themselves with for the last five years. and in 2013, ucla cryptographer amit sahai, homomorphic encryption pioneer craig gentry and several other researchers figured out how to do it. does the indistinguishability obfuscator actually hide private data inside the program? to see what the answer is, consider the following. suppose your secret password is bobalot_13048, and the sha256 of the password starts with 00b9bbe6345de82f. now, construct two programs. a just outputs 00b9bbe6345de82f, whereas b actually stores bobalot_13048 inside, and when you run it it computes sha256(bobalot_13048) and returns the first 16 hex digits of the output. according to the indistinguishability property, o(a) and o(b) are indistinguishable. if there was some way to extract bobalot_13048 from b, it would therefore be possible to extract bobalot_13048 from a, which essentially implies that you can break sha256 (or by extension any hash function for that matter). by standard assumptions, this is impossible, so therefore the obfuscator must also make it impossible to uncover bobalot_13048 from b. thus, we can be pretty sure that sahai’s obfuscator does actually obfuscate. so what’s the point? in many ways, code obfuscation is one of the holy grails of cryptography. to understand why, consider just how easily nearly every other primitive can be implemented with it. want public key encryption? take any symmetric-key encryption scheme, and construct a decryptor with your secret key built in. obfuscate it, and publish that on the web. you now have a public key. want a signature scheme? public key encryption provides that for you as an easy corollary. want fully homomorphic encryption? construct a program which takes two numbers as an input, decrypts them, adds the results, and encrypts it, and obfuscate the program. do the same for multiplication, send both programs to the server, and the server will swap in your adder and multiplier into its code and perform your computation. however, aside from that, obfuscation is powerful in another key way, and one which has profound consequences particularly in the field of cryptocurrencies and decentralized autonomous organizations: publicly running contracts can now contain private data. on top of second-generation blockchains like ethereum, it will be possible to run so-called “autonomous agents” (or, when the agents primarily serve as a voting system between human actors, “decentralized autonomous organizations”) whose code gets executed entirely on the blockchain, and which have the power to maintain a currency balance and send transactions inside the ethereum system. for example, one might have a contract for a non-profit organization that contains a currency balance, with a rule that the funds can be withdrawn or spent if 67% of the organization’s members agree on the amount and destination to send. unlike bitcoin’s vaguely similar multisig functionality, the rules can be extremely flexible, for example allowing a maximum of 1% per day to be withdrawn with only 33% consent, or making the organization a for-profit company whose shares are tradable and whose shareholders automatically receive dividends. up until now it has been thought that such contracts are fundamentally limited – they can only have an effect inside the ethereum network, and perhaps other systems which deliberately set themselves up to listen to the ethereum network. with obfuscation, however, there are new possibilities. consider the simplest case: an obfuscated ethereum contract can contain a private key to an address inside the bitcoin network, and use that private key to sign bitcoin transactions when the contract’s conditions are met. thus, as long as the ethereum blockchain exists, one can effectively use ethereum as a sort of controller for money that exists inside of bitcoin. from there, however, things only get more interesting. suppose now that you want a decentralized organization to have control of a bank account. with an obfuscated contract, you can have the contract hold the login details to the website of a bank account, and have the contract carry out an entire https session with the bank, logging in and then authorizing certain transfers. you would need some user to act as an intermediary sending packets between the bank and the contract, but this would be a completely trust-free role, like an internet service provider, and anyone could trivially do it and even receive a reward for the task. autonomous agents can now also have social networking accounts, accounts to virtual private servers to carry out more heavy-duty computations than what can be done on a blockchain, and pretty much anything that a normal human or proprietary server can. looking forward thus, we can see that in the next few years decentralized autonomous organizations are potentially going to become much more powerful than they are today. but what are the consequences going to be? in the developed world, the hope is that there will be a massive reduction in the cost of setting up a new business, organization or partnership, and a tool for creating organizations that are much more difficult to corrupt. much of the time, organizations are bound by rules which are really little more than gentlemen’s agreements in practice, and once some of the organization’s members gain a certain measure of power they gain the ability to twist every interpretation in their favor. up until now, the only partial solution was codifying certain rules into contracts and laws – a solution which has its strengths, but which also has its weaknesses, as laws are numerous and very complicated to navigate without the help of a (often very expensive) professional. with daos, there is now also another alternative: making an organization whose organizational bylaws are 100% crystal clear, embedded in mathematical code. of course, there are many things with definitions that are simply too fuzzy to be mathematically defined; in those cases, we will still need some arbitrators, but their role will be reduced to a limited commodity-like function circumscribed by the contract, rather than having potentially full control over everything. in the developing world, however, things will be much more drastic. the developed world has access to a legal system that is at times semi-corrupt, but whose main problems are otherwise simply that it’s too biased toward lawyers and too outdated, bureaucratic and inefficient. the developing world, on the other hand, is plagues by legal systems that are fully corrupt at best, and actively conspiring to pillage their subjects at worst. there, nearly all businesses are gentleman’s agreements, and opportunities for people to betray each other exist at every step. the mathematically encoded organizational bylaws that daos can have are not just an alternative; they may potentially be the first legal system that people have that is actually there to help them. arbitrators can build up their reputations online, as can organizations themselves. ultimately, perhaps on-blockchain voting, like that being pioneered by bitcongress, may even form a basis for new experimental governments. if africa can leapfrog straight from word of mouth communications to mobile phones, why not go from tribal legal systems with the interference of local governments straight to daos? many will of course be concerned that having uncontrollable entities moving money around is dangerous, as there are considerable possibilities for criminal activity with these kinds of powers. to that, however, one can make two simple rebuttals. first, although these decentralized autonomous organizations will be impossible to shut down, they will certainly be very easy to monitor and track every step of the way. it will be possible to detect when one of these entities makes a transaction, it will be easy to see what its balance and relationships are, and it will be possible to glean a lot of information about its organizational structure if voting is done on the blockchain. much like bitcoin, daos are likely far too transparent to be practical for much of the underworld; as fincen director jennifer shasky calvery has recently said, “cash is probably still the best medium for laundering money”. second, ultimately daos cannot do anything normal organizations cannot do; all they are is a set of voting rules for a group of humans or other human-controlled agents to manage ownership of digital assets. even if a dao cannot be shut down, its members certainly can be just as if they were running a plain old normal organization offline. whatever the dominant applications of this new technology turn out to be, one thing is looking more and more certain: cryptography and distributed consensus are about to make the world a whole lot more interesting. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements announcement on planned withdrawal from exodus | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search announcement on planned withdrawal from exodus posted by vitalik buterin on august 8, 2014 research & development now that the first two weeks of the ether sale are over, and over 50 million eth has been sold, we intend to soon make a transaction to begin using the funds to repay loans and kickstart the process of setting up our development hubs and expanding our staff. we have made a commitment to be highly transparent about how we spend the funds, and that is a commitment that we intend to live up to; to that end, we have already released an intended use of revenue chart and a roadmap to show how we intend to spend the btc. more recently, the community has followed up with a wonderful infographic on cointelegraph using the information that we have posted. now, we intend to release some additional information about the nature of our first withdrawal transaction. the intent is to withdraw 4150 btc from our exodus address within the next 48 hours. we reserve the right to withdraw up to 850 btc more if needed before the end of the 42 day duration of the sale, but at this point it is likely that the remainder of the btc in the address will remain unused until the sale ends. of this amount, 2650 btc will be distributed to pay for loans for prior expenses. individuals who have contributed loans to the project will receive repayment in btc directly; "we" will not be selling any portion of this 2650 btc on exchanges ourselves, although individuals may choose to independently convert the btc that they receive into fiat after the fact. individuals also have the choice of taking the repayment in ether; in those cases, we will simply not send the btc, and once all repayments have been processed we will publish all of the additional eth that has been sold in this way (note that this is equivalent to sending individuals their btc and letting the recipients send it right back into the exodus). the remaining 1500 btc will be sent to a wallet controlled by đξv, our development arm, and will be used to establish our sites in berlin and amsterdam and begin hiring developers; some of this amount may be converted into eur, gbp or chf (eg. to pay for rent), and the remainder will be held as btc. the following spreadsheet provides a rough categorization of how the backpay and forward-pay expenses are to be ultimately distributed. https://docs.google.com/a/ethereum.org/spreadsheets/d/1yqymlknf9tibarjyrkhef-ivnmga6ffvhjnqh_no_ao/edit#gid=0 the largest category is pay for individuals, covering core developers, web developers and art, communications, branding and business development, and among the expenses the largest is legal at 296,000followedbyrentat296,000 followed by rent at 296,000followedbyrentat111,000 (including a $16,500 security deposit which is theoretically refundable and pre-payment up to feb 2015) and the other categories you can see for yourself by looking at the chart. going forward, the primary change is that expenditures are now going to be much more focused on paying for development. our intent is to have our development centers in berlin and amsterdam, with a smaller presence in toronto and london to cover communications, marketing and branding; the extent of our presence in san francisco / silicon valley and possibly other locations is still to be determined and will be done based on cost-benefit analysis. additionally, note that the distribution of the endowment is quasi-public; although names of all individuals are not published (though everyone is free to disclose their own portion voluntarily, and the owners of the largest pieces can be partially inferred from public information), the percentages are available for view at https://docs.google.com/spreadsheets/d/1gs9pzsdmx9lk0xgskedr_aoi02riq3mpryventvum68/edit#gid=0. in the future, we intend to continue to uphold and step up our commitment to transparency, releasing details on how funds are being spent and on the progress of the project; if you are interested, feel free to follow our blog and the public blockchain. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements ethereum comms announcement | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search ethereum comms announcement posted by vitalik buterin on september 18, 2015 organizational the foundation is currently in the phase of restructuring its communications activities. several members of our current communications team in london are soon leaving or reducing their involvement in the foundation in order to pursue for-profit ventures on top of the ethereum ecosystem; we wish them the best of luck. and so, we have both the necessity and a unique opportunity to "reboot" that side of the organization and take another look at how the ethereum foundation interacts with the community. as some initial steps, we are going to do the following: we will make an effort to de-emphasize skype, and emphasize gitter as a means of real-time communication for developers. gitter has the advantages that (i) it's easier to quickly jump in and participate, and (ii) chat rooms are public and visible to everyone by default. currently, the primary active gitter rooms are: https://gitter.im/ethereum/cpp-ethereum https://gitter.im/ethereum/pyethereum https://gitter.im/ethereum/go-ethereum https://gitter.im/ethereum/mist https://gitter.im/ethereum/web3.js we will continue our general direction of increasing permissiveness that we began with our recent changes to branding guidelines, and emphasis on maintaining norms of common sense and civility over strict rules. we are not following in the footsteps of /r/bitcoin's theymos. discussion of ethereumxt (i suppose the closest equivalent we have is expanse, with its 10x higher gas limit) is not banned. we will de-emphasize the "eth dev" brand (with the exception of "devcon") and focus attention on "ethereum" going forward in the medium term, we are in the process of substantially re-examining our strategy internally including meetups, general community outreach, trademark policy, developer documentation, and communicating information on protocol updates (e.g the most pressing short-term updates will be at the networking level to faciliate support of light clients, and larger future changes will be for proof of stake, scalability, etc), as well as interacting with the rapidly growing number of both individual and organizational/corporate ethereum developers outside of the foundation proper. we will continue releasing more concrete info on both this and other topics as it becomes ready, and welcome community input on any of these issues. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-4758: deactivate selfdestruct ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-4758: deactivate selfdestruct deactivate selfdestruct by changing it to sendall, which does recover all funds to the caller but does not delete any code or storage. authors guillaume ballet (@gballet), vitalik buterin (@vbuterin), dankrad feist (@dankrad) created 2022-02-03 discussion link https://ethereum-magicians.org/t/eip-4758-deactivate-selfdestruct/8710 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip renames the selfdestruct opcode to sendall, and replaces its functionality. the new functionality will be only to send all ether in the account to the caller. motivation the selfdestruct opcode requires large changes to the state of an account, in particular removing all code and storage. this will not be possible in the future with verkle trees: each account will be stored in many different account keys, which will not be obviously connected to the root account. this eip implements this change. applications that only use selfdestruct to retrieve funds will still work. specification the selfdestruct opcode is renamed to sendall, and now only immediately moves all eth in the account to the target; it no longer destroys code or storage or alters the nonce all refunds related to selfdestruct are removed rationale getting rid of the selfdestruct opcode has been considered in the past, and there are currently no strong reasons to use it. disabling it will be a requirement for statelessness. backwards compatibility this eip requires a hard fork, since it modifies consensus rules. few applications are affected by this change. the only use that breaks is where a contract is re-created at the same address using create2 (after a selfdestruct). security considerations the following applications of selfdestruct will be broken and applications that use it in this way are not safe anymore: any use where selfdestruct is used to burn non-eth token balances, such as eip-20), inside a contract. we do not know of any such use (since it can easily be done by sending to a burn address this seems an unlikely way to use selfdestruct) where create2 is used to redeploy a contract in the same place. there are two ways in which this can fail: the destruction prevents the contract from being used outside of a certain context. for example, the contract allows anyone to withdraw funds, but selfdestruct is used at the end of an operation to prevent others from doing this. this type of operation can easily be modified to not depend on selfdestruct. the selfdestruct operation is used in order to make a contract upgradable. this is not supported anymore and delegates should be used. copyright copyright and related rights waived via cc0. citation please cite this document as: guillaume ballet (@gballet), vitalik buterin (@vbuterin), dankrad feist (@dankrad), "eip-4758: deactivate selfdestruct [draft]," ethereum improvement proposals, no. 4758, february 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-4758. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5793: eth/68 add tx type to tx announcement ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: networking eip-5793: eth/68 add tx type to tx announcement adds the transaction type and transaction size to tx announcement messages in the wire protocol authors marius van der wijden (@mariusvanderwijden) created 2022-10-18 last call deadline 2024-02-13 requires eip-2464, eip-2481, eip-4938 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract the ethereum wire protocol defines request and response messages for exchanging data between clients. the newpooledtransactionhashes message announces transactions available in the node. this eip extends this announcement message such that beside the transaction hashes, the node sends the transaction types and their sizes (as defined in eip-2718) as well. motivation the newpooledtransactionhashes message announces transaction hashes, allowing the peer to selectively fetch transactions it does not yet have. eip-4844 introduces a new transaction type for blob transactions. since these blob transactions are large, naively broadcasting them to sqrt(peers) could significantly increase bandwidth requirements. adding the transaction type and the size to the announcement message will allow nodes to select which transactions they want to fetch and also allow them to load balance or throttle peers based on past behavior. the added metadata fields will also enable future upgradeless protocol tweaks to prevent certain transaction type (e.g. blob transactions) or certain transaction sizes (e.g. 128kb+) from being blindly broadcast to many peers. enforcing announcements only and retrieval on demand would ensure a much more predictable networking behavior, limiting the amplification effect of transaction propagation dos attack. specification modify the newpooledtransactionhashes (0x08) message: (eth/67): [hash_0: b_32, hash_1: b_32, ...] (eth/68): [types: b, [size_0: p, size_1: p, ...], [hash_0: b_32, hash_1: b_32, ...]] the new types element refers to the transaction types of the announced hashes. note the transaction types are packed as a ‘byte array’ instead of a list. the size_0, size_1 etc. elements refer to the transaction sizes of the announced hashes. rationale this change will make the eth protocol future-proof for new transaction types that might not be relevant for all nodes. it gives the receiving node better control over the data it fetches from the peer as well as allow throttling the download of specific types. the types message element is a byte array because early implementations of this eip erroneously implemented it that way. it was later decided to keep this behavior in order to minimize work. backwards compatibility this eip changes the eth protocol and requires rolling out a new version, eth/68. supporting multiple versions of a wire protocol is possible. rolling out a new version does not break older clients immediately, since they can keep using protocol version eth/67. this eip does not change consensus rules of the evm and does not require a hard fork. security considerations none copyright copyright and related rights waived via cc0. citation please cite this document as: marius van der wijden (@mariusvanderwijden), "eip-5793: eth/68 add tx type to tx announcement [draft]," ethereum improvement proposals, no. 5793, october 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5793. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1355: ethash 1a ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-1355: ethash 1a authors paweł bylica (@chfast), jean m. cyr (@jean-m-cyr) created 2018-08-26 discussion link https://ethereum-magicians.org/t/eip-1355-ethash-1a/1167 table of contents motivation specification rationale fnv primes copyright motivation provide minimal set of changes to ethash algorithm to hinder and delay the adoption of asic based mining. specification define hash function fnv1a() as def fnv1a(v1, v2): return ((v1 ^ v2) * fnv1a_prime) % 2**32 where fnv1a_prime is 16777499 or 16777639. change the hash function that determines the dag item index in ethash algorithm from fnv() to new fnv1a(). in main loop change p = fnv(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes to p = fnv1a(i ^ s[0], mix[i % w]) % (n // mixhashes) * mixhashes rationale the usual argument for decentralization and network security. unless programmable, an asic is hardwired to perform sequential operations in a given order. fnv1a changes the order in which an exclusive-or and a multiply are applied, effectively disabling the current wave of asics. a second objective is minimize ethash changes to be the least disruptive, to facilitate rapid development, and to lower the analysis and test requirements. minimizing changes to ethash reduces risk associated with updating all affected network components, and also reduces the risk of detuning existing gpus. it’s expected that this specific change would have no effect on existing gpu performance. changing fnv to fnv1a has no cryptographic implications. it is merely an efficient hash function with good dispersion characteristics used to scramble dag indexing. we remain focused on risk mitigation by reducing the need for rigorous cryptographic analysis. fnv primes the 16777639 satisfies all requirements from wikipedia. the 16777499 is preferred by fnv authors but not used in the reference fnv implementation because of historical reasons. see a few remarks on fnv primes. copyright this work is licensed under a creative commons attribution-noncommercial-sharealike 4.0 international license. citation please cite this document as: paweł bylica (@chfast), jean m. cyr (@jean-m-cyr), "eip-1355: ethash 1a [draft]," ethereum improvement proposals, no. 1355, august 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1355. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. how do you know ethereum is secure? | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search how do you know ethereum is secure? posted by jutta steiner on july 7, 2015 research & development as i'm writing this, i’m sitting in the london office and pondering how to give you a good overview about the work we’ve been doing to secure ethereum’s protocols, clients and p2p-network. as you might remember, i joined the ethereum team at the end of last year to manage the security audit. as spring has passed and summer arrived and meanwhile several audits finished, it’s now a good time for me to share some results from the inspection of the world computer’s machine room. ;-) this much is clear, as much as the delivery of the clients is an elaborate product development process, it is an exciting yet heavily complex research effort. the latter is the reason why even the best planned development schedule is subject to change as we discover more about our problem domain. the security audit started at the end of last year with the development of a general strategy for ensuring maximum security for ethereum. as you know, we have a security driven, rather than a schedule driven development process. with this in mind, we put together a multi-tiered audit approach consisting of: analyses of the new protocols and algorithms by established blockchain researchers and specialised software security companies end-to-end audit of protocols and implementation by a world-class expert security consultancy (go followed by c++ and a basic audit for the educational python client), as well as the bug bounty program. the analyses of the new protocols and algorithms covered topics like the security of: the gas economics the newly devised asic-resistant proof of work puzzle as well as the economic incentivisation of mining nodes. the “crowd-sourced” audit component started around christmas along with our bug bounty program. we had set aside an 11-digit satoshi amount to reward people who found bugs in our code. we’ve seen very high quality submissions to our bug bounty program and hunters received corresponding rewards. the bug bounty program is is still running and we need further submissions to use up the allocated budget... the first major security audit (covering the gas economics and pow puzzle) by security consultancy least authority was started in january and continued until the end of winter. we are very glad that we agreed with most of our external auditors that those audit reports will be publicly available once the audit work and fixing of the findings is completed. so along with this blog post, we are delighted to present the least authority audit report and accompanying blog post. in addition, the report contains helpful recommendations for ðapp developers to ensure secure design and deployment of contracts. we expect to publish further reports as they become available. we have also engaged another software security firm at the beginning of the year to provide audit coverage on the go implementation. given the increased security that comes with multiple clients and as gav mentioned in his previous post, we have also decided to give the python and c++ audit a lightweight security audit starting early july. the c++ code will receive a full audit right after – our goal with this approach is to ensure several available audited clients as early as possible during the release process. we kicked off this most encompassing audit for the go client, aka the “end to end audit”, in february with a one-week workshop that would be followed by weeks of regular check-in calls and weekly audit reports. the audit was embedded in a comprehensive process for bug tracking and fixing, managed and thoroughly tracked on github by gustav with christoph and dimitry coding up the corresponding required tests. as the name implies, the end-to-end audit was scoped to cover “everything” (from networking to the ethereum vm to syncing layer to pow) so that at least one auditor would have cross checked the various core layers of ethereum. one of the consultants recently summarized the situation pretty succinctly: “to be honest, the testing needs of ethereum are more complex than anything i’ve looked at before”. as gav reported in his last blog post, because of the significant changes in the networking and syncing strategy we eventually decided to commission further audit work for go – which we are about to finish this week. the kick-off for the end-to-end c++ and basic python audits is taking place now. the audit work with subsequent bug fixing and regression testing as well as related refactoring and redesign (of networking and syncing layer) make up the majority of work that’s keeping the developers busy right now. likewise, fixing of findings, redesign and regression testing are the reason for the delay in the delivery. in addition, the olympic testing phase has taught us a great deal about resiliency under various scenarios, such as slow connections, bad peers, odd behaving peers and outdated peers. the greatest challenge so far has been fighting off and recovering from forks. we learnt a lot from the recovery attempts in terms of required processes when it comes to dealing with these type of scenarios and incidents. it might not come as a surprise that the various audits represent a significant expenditure – and we think money that could not be better invested. as we draw closer to release, security and reliability is increasingly uppermost in our minds, particularly given the handful of critical issues found in the olympic test release. we are very grateful for the enthusiasm and thorough work that all auditors have done so far. their work helped us sharpen the specification in the yellow paper and to weed out ambiguity and fix several subtle issues, and they helped with identifying a number of implementation bugs. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-7495: ssz stablecontainer ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: core eip-7495: ssz stablecontainer new ssz type to represent a flexible container with stable serialization and merkleization authors etan kissling (@etan-status) created 2023-08-18 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification type definition stability guarantees serialization deserialization merkleization variant[s] rationale what are the problems solved by stablecontainer[n]? why not union[t, u, v]? why not a container full of optional[t]? backwards compatibility test cases reference implementation security considerations copyright abstract this eip introduces a new simple serialize (ssz) type to represent stablecontainer[n] values. a stablecontainer[n] is an ssz container with stable serialization and merkleization even when individual fields become optional or new fields are introduced in the future. motivation stable containers are currently not representable in ssz. adding support provides these benefits: stable signatures: signing roots derived from a stablecontainer[n] never change. in the context of ethereum, this is useful for transaction signatures that are expected to remain valid even when future updates introduce additional transaction fields. likewise, the overall transaction root remains stable and can be used as a perpetual transaction id. stable merkle proofs: merkle proof verifiers that check specific fields of a stablecontainer[n] do not need continuous updating when future updates introduce additional fields. common fields always merkleize at the same generalized indices. optional fields: current ssz formats do not support optional fields, prompting designs to use zero values instead. with stablecontainer[n], the ssz serialization is compact; inactive fields do not consume space. 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. type definition similar to the regular ssz container, stablecontainer[n] defines an ordered heterogeneous collection of fields. n indicates the potential maximum number of fields to which it can ever grow in the future. n must be > 0. as part of a stablecontainer[n], fields of type optional[t] may be defined. such fields can either represent a present value of ssz type t, or indicate absence of a value (indicated by none). the default value of an optional[t] is none. class example(stablecontainer[32]): a: uint64 b: optional[uint32] c: uint16 for the purpose of serialization, stablecontainer[n] is always considered “variable-size” regardless of the individual field types. stability guarantees the serialization and merkleization of a stablecontainer[n] remains stable as long as: the maximum capacity n does not change the order of fields does not change new fields are always added to the end required fields remain required t, or become an optional[t] optional fields remain optional[t], or become a required t when an optional field becomes required, existing messages still have stable serialization and merkleization, but will be rejected on deserialization if not present. serialization serialization of stablecontainer[n] is defined similarly to the existing logic for container. notable changes are: a bitvector[n] is constructed, indicating active fields within the stablecontainer[n]. for required fields t and optional fields optional[t] with a present value (not none), a true bit is included. for optional fields optional[t] with a none value, a false bit is included. the bitvector[n] is padded with false bits up through length n only active fields are serialized, i.e., fields with a corresponding true bit in the bitvector[n] the serialization of the bitvector[n] is prepended to the serialized active fields if variable-length fields are serialized, their offsets are relative to the start of serialized active fields, after the bitvector[n] def is_active_field(element): return not is_optional(element) or element is not none # determine active fields active_fields = bitvector[n](([is_active_field(element) for element in value] + [false] * n)[:n]) active_values = [element for element in value if is_active_field(element)] # recursively serialize fixed_parts = [serialize(element) if not is_variable_size(element) else none for element in active_values] variable_parts = [serialize(element) if is_variable_size(element) else b"" for element in active_values] # compute and check lengths fixed_lengths = [len(part) if part != none else bytes_per_length_offset for part in fixed_parts] variable_lengths = [len(part) for part in variable_parts] assert sum(fixed_lengths + variable_lengths) < 2**(bytes_per_length_offset * bits_per_byte) # interleave offsets of variable-size parts with fixed-size parts variable_offsets = [serialize(uint32(sum(fixed_lengths + variable_lengths[:i]))) for i in range(len(active_values))] fixed_parts = [part if part != none else variable_offsets[i] for i, part in enumerate(fixed_parts)] # return the concatenation of the active fields `bitvector` with the active # fixed-size parts (offsets interleaved) and the active variable-size parts return serialize(active_fields) + b"".join(fixed_parts + variable_parts) deserialization deserialization of a stablecontainer[n] starts by deserializing a bitvector[n]. that value must be validated: for each required field, the corresponding bit in the bitvector[n] must be true for each optional field, the corresponding bit in the bitvector[n] is not restricted all extra bits in the bitvector[n] that exceed the number of fields must be false the rest of the data is deserialized same as a regular ssz container, consulting the bitvector[n] to determine what optional fields are present in the data. absent fields are skipped during deserialization and assigned none values. merkleization the merkleization specification is extended with the following helper functions: chunk_count(type): calculate the amount of leafs for merkleization of the type. stablecontainer[n]: always n, regardless of the actual number of fields in the type definition mix_in_aux: given a merkle root root and an auxiliary ssz object root aux return hash(root + aux). to merkleize a stablecontainer[n], a bitvector[n] is constructed, indicating active fields within the stablecontainer[n], using the same process as during serialization. merkleization hash_tree_root(value) of an object value is extended with: mix_in_aux(merkleize(([hash_tree_root(element) if is_active_field(element) else bytes32() for element in value.data] + [bytes32()] * n)[:n]), hash_tree_root(value.active_fields)) if value is a stablecontainer[n]. variant[s] for the purpose of type safety, variant[s] is defined to serve as a subset of stablecontainer s. while s still determines how the variant[s] is serialized and merkleized, variant[s] may implement additional restrictions on valid combinations of fields. fields in variant[s] may have a different order than in s; the canonical order in s is always used for serialization and merkleization regardless of any alternative orders in variant[s] fields in variant[s] may be required, despite being optional in s fields in variant[s] may be missing, despite being optional in s all fields that are required in s must be present in variant[s] # serialization and merkleization format class shape(stablecontainer[4]): side: optional[uint16] color: uint8 radius: optional[uint16] # valid variants class square(variant[shape]): side: uint16 color: uint8 class circle(variant[shape]): radius: uint16 color: uint8 in addition, oneof[s] is defined to provide a select_variant helper function for determining the variant[s] to use when parsing s. the select_variant helper function may incorporate environmental information, e.g., the fork schedule. class anyshape(oneof[shape]): @classmethod def select_variant(cls, value: shape, circle_allowed = true) -> type[shape]: if value.radius is not none: assert circle_allowed return circle if value.side is not none: return square assert false the extent and syntax in which variant[s] and oneof[s] are supported may differ among underlying ssz implementations. where it supports clarity, specifications should use variant[s] and oneof[s] as defined here. rationale what are the problems solved by stablecontainer[n]? current ssz types are only stable within one version of a specification, i.e., one fork of ethereum. this is alright for messages pertaining to a specific fork, such as attestations or beacon blocks. however, it is a limitation for messages that are expected to remain valid across forks, such as transactions or receipts. in order to support evolving the features of such perpetually valid message types, a new ssz scheme needs to be defined. to avoid restricting design space, the scheme has to support extension with new fields, obsolescence of old fields, and new combinations of existing fields. when such adjustments occur, old messages must still deserialize correctly and must retain their original merkle root. why not union[t, u, v]? typically, the individual union cases share some form of thematic overlap, sharing certain fields with each other. in a union, shared fields are not necessarily merkleized at the same generalized indices. therefore, merkle proof systems would have to be updated each time that a new flavor is introduced, even when the actual changes are not of interest to the particular system. furthermore, ssz union types are currently not used in any final ethereum specification and do not have a finalized design themselves. the stablecontainer[n] serializes very similar to current union[t, u, v] proposals, with the difference being a bitvector[n] as a prefix instead of a selector byte. this means that the serialized byte lengths are comparable. why not a container full of optional[t]? if optional[t] is modeled as an ssz type, each individual field introduces serialization and merkleization overhead. as an optional[t] would be required to be “variable-size”, lots of additional offset bytes would have to be used in the serialization. for merkleization, each individual optional[t] would require mixing in a bit to indicate presence or absence of the value. additionally, every time that the number of fields reaches a new power of 2, the merkle roots break, as the number of chunks doubles. the stablecontainer[n] solves this by artificially extending the merkle tree to n chunks regardless of the actual number of fields currently specified. because n is constant across specification versions, the merkle tree shape remains stable. the overhead of the additional empty placeholder leaves only affects serialization of the bitvector[n] (1 byte per 8 leaves); the number of required hashes during merkleization only grows logarithmically with n. backwards compatibility stablecontainer[n] is a new ssz type and does not conflict with other ssz types currently in use. test cases see eip assets. reference implementation see eip assets, based on protolambda/remerkleable. security considerations none copyright copyright and related rights waived via cc0. citation please cite this document as: etan kissling (@etan-status), "eip-7495: ssz stablecontainer [draft]," ethereum improvement proposals, no. 7495, august 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7495. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1523: standard for insurance policies as erc-721 non fungible tokens ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1523: standard for insurance policies as erc-721 non fungible tokens authors christoph mussenbrock (@christoph2806) created 2018-10-10 discussion link https://github.com/ethereum/eips/issues/1523 requires eip-721 table of contents simple summary abstract motivation specification additional parameters for the metadata json schema rationale mandatory parameters optional parameters on-chain vs. off-chain metadata backwards compatibility test cases implementation copyright simple summary a standard interface for insurance policies, based on erc 721. abstract the following standard allows for the implementation of a standard api for insurance policies within smart contracts. insurance policies are financial assets which are unique in some aspects, as they are connected to a customer, a specific risk, or have other unique properties like premium, period, carrier, underwriter etc. nevertheless, there are many potential applications where insurance policies can be traded, transferred or otherwise treated as an asset. the erc 721 standard already provides the standard and technical means to handle policies as a specific class of non fungible tokens. insurance in this proposal, we define a minimum metadata structure with properties which are common to the greatest possible class of policies. motivation for a decentralized insurance protocol, a standard for insurance policies is crucial for interoperability of the involved services and application. it allows policies to be bundled, securitized, traded in a uniform and flexible way by many independent actors like syndicates, brokers, and insurance companies. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. an erc-1523 compliant insurance policy is a non-fungible token which must adhere to the erc-721 token standard and must implement theerc721metadata and the erc721enumerable interface: /// @title erc-1523 insurance policy standard /// note: the erc-165 identifier for this interface is 0x5a04be32 interface erc1523 /* is erc721, erc721metadata, erc721enumerable */ { } the implementor may choose values for the name and symbol. the policy metadata extension is recommended for erc-1523 smart contracts. this allows your smart contract to be interrogated for policy metadata. /// @title erc-1523 insurance policy standard, optional policy metadata extension /// @dev see ... /// note: the erc-165 identifier for this interface is 0x5a04be32 interface erc1523policymetadata /* is erc1523 */ { /// @notice metadata string for a given property. /// properties are identified via hash of their property path. /// e.g. the property "name" in the erc721 metadata json schema has the path /properties/name /// and the property path hash is the keccak256() of this property path. /// this allows for efficient addressing of arbitrary properties, as the set of properties is potentially unlimited. /// @dev throws if `_propertypathhash` is not a valid property path hash. function policymetadata(uint256 _tokenid, bytes32 _propertypathhash) external view returns (string _property); } in analogy to the “erc721 metadata json schema”, the tokenuri must point to a json file with the following properties: { "title": "asset metadata", "type": "object", "properties": { "name": { "type": "string", "description": "identifies the asset to which this nft represents", }, "description": { "type": "string", "description": "describes the asset to which this nft represents", }, \[additional parameters according to the following table\] } } additional parameters for the metadata json schema parameter type mandatory description carrier string yes describes the carrier which takes the primary risk risk string yes describes the risk status string yes describes the status of the policy, e.g. applied for, underwritten, expired parameters string no describes further parameters characterizing the risk terms string no describes legal terms & conditions which apply for this policy premium string no a string representation of the premium, may contain currency denominator sum_insured string no a string representation of the sum insured, may contain currency denominator parameters which are mandatory must be included in the metadata json. other parameters may be included. however, the proposed optional parameters should be used for the intended purpose, so e.g. if the premium amount would be included in the metadata, the parameter name should be “premium”. all parameters may be plain text or may also be uris pointing to resources which contain the respective information, and which may be protected by an authentication mechanism. rationale insurance policies form an important class of financial assets, and it is natural to express those assets as a class of non-fungible tokens which adhere to the established erc-721 standard. we propose a standard for the accompanying metadata structures which are needed to uniquely define an insurance policy. standardization is key because we expect decentralized insurance to receive widespread adoption and it is crucial to establish a unified standard to enable composability and the creation of universal toolsets. we therefore propose a standardized naming scheme for the different parameters describing an insurance policy. we propose three mandatory parameters which need to be included in every nft and further parameters which may be used, and for which we only standardize the naming conventions. mandatory parameters while policies can have a multitude of possible properties, it is common that policies are issued by some entity, which is basically the entity responsible for paying out claims. second, an insurance policy is typically related to a specific risk. some risks are unique, but there are cases where many policies share the same risk (e.g. all flight delay policies for the same flight). in general, the relation of policies to risks is a many-to-one relation with the special case of a one-to-one relation. third, a policy has a lifecycle of different statuses. therefore the nft we believe that those four properties are necessary to describe a policy. for many applications, those properties may be even sufficient. optional parameters most policies need more parameters to characterize the risk and other features, like premium, period etc. the naming conventions are listed in the above table. however, any implementation may chose to implement more properties. on-chain vs. off-chain metadata for some applications it will be sufficient to store the metadata in an off-chain repository or database which can be addressed by the tokenuri resource locator. for more advanced applications, it can be desirable to have metadata available on-chain. therefore, we require that the tokenuri must point to a json with the above structure, while the implementation of the policymetadata function is optional. backwards compatibility test cases implementation copyright copyright and related rights waived via cc0. citation please cite this document as: christoph mussenbrock (@christoph2806), "erc-1523: standard for insurance policies as erc-721 non fungible tokens [draft]," ethereum improvement proposals, no. 1523, october 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1523. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5988: add poseidon hash function precompile ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-5988: add poseidon hash function precompile add a precompiled contract which implements the hash function used in the poseidon cryptographic hashing algorithm authors abdelhamid bakhta (@abdelhamidbakhta), eli ben sasson (@elistark), avihu levy (@avihu28), david levit gurevich (@davidlevitgurevich) created 2022-11-15 discussion link https://ethereum-magicians.org/t/eip-5988-add-poseidon-hash-function-precompile/11772 table of contents abstract motivation specification parameters rationale backwards compatibility test cases security considerations security of the poseidon parameters papers and research related to poseidon security copyright abstract this eip introduces a new precompiled contract which implements the hash function used in the poseidon cryptographic hashing algorithm, for the purpose of allowing interoperability between the evm and zk / validity rollups, as well as introducing more flexible cryptographic hash primitives to the evm. motivation poseidon is an arithmetic hash function that is designed to be efficient for zero-knowledge proof systems. ethereum adopts a rollup centric roadmap and hence must adopt facilities for l2s to be able to communicate with the evm in an optimal manner. zk-rollups have particular needs for cryptographic hash functions that can allow for efficient verification of proofs. the poseidon hash function is a set of permutations over a prime field, which makes it particularly well-suited for the purpose of building efficient zk / validity rollups on ethereum. poseidon is one of the most efficient hashing algorithms that can be used in this context. moreover it is compatible with all major proof systems (snarks, starks, bulletproofs, etc…). this makes it a good candidate for a precompile that can be used by many different zk-rollups. an important point to note is that zk rollups using poseidon have chosen different sets of parameters, which makes it harder to build a single precompile for all of them. however, we can still build a generic precompile that supports arbitrary parameters, and allow the zk rollups to choose the parameters they want to use. this is the approach that we have taken in this eip. specification the keywords “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. parameters constant value fork_blknum tbd gas_cost tbd poseidon_precompile_address 0xa here are the poseidon parameters that the precompile will support: parameter name description encoding size (in bytes) comments p prime field modulus 32 security_level security level measured in bits. denoted m in the poseidon paper 2 alpha power of s-box 1 input_rate size of input 2 t size of the state 1 full_round number of full rounds. denoted as r_f in the poseidon paper. 1 partial_round number of partial rounds. denoted as r_p in the poseidon paper. 1 input input to the hash function input_rate * 32 the encoding of the precompile input is the following: [32 bytes for p][2 bytes for security_level][1 byte for alpha][2 bytes for input_rate][1 byte for t][1 byte for full_round][1 byte for partial_round][input_rate * 32 bytes for input] the precompile should compute the hash function as specified in the poseidon paper and return hash output. rationale todo: add rationale todo: add rationale for gas cost e.g. benchmark and computation cost estimation. backwards compatibility there is very little risk of breaking backwards-compatibility with this eip, the sole issue being if someone were to build a contract relying on the address at 0xposeidon_precompile_address being empty. the likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value with negligible risk of collision. test cases the poseidon reference implementation contains test vectors that can be used to test the precompile. those tests are available here. security considerations quoting vitalik buterin from arithmetic hash based alternatives to kzg for proto-danksharding thread on ethresearch: the poseidon hash function was officially introduced in 2019. since then it has seen considerable attempts at cryptanalysis and optimization. however, it is still very young compared to popular “traditional” hash functions (eg. sha256 and keccak), and its general approach of accepting a high level of algebraic structure to minimize constraint count is relatively untested. there are layer-2 systems live on the ethereum network and other systems that already rely on these hashes for their security, and so far they have seen no bugs for this reason. use of poseidon in production is still somewhat “brave” compared to decades-old tried-and-tested hash functions, but this risk should be weighed against the risks of proposed alternatives (eg. pairings with trusted setups) and the risks associated with centralization that might come as a result of dependence on powerful provers that can prove sha256. it is true that arithmetic hash functions are relatively untested compared to traditional hash functions. however, poseidon has been thoroughly tested and is considered secure by multiple independent research groups and layers 2 systems are already using it in production (starkware, polygon, loopring) and also by other projects (e.g. filecoin). moreover, the impact of a potential vulnerability in the poseidon hash function would be limited to the rollups that use it. we can see the same rationale for the kzg ceremony in the eip-4844, arguing that the risk of a vulnerability in the kzg ceremony is limited to the rollups that use it. list of projects (non exhaustive) using poseidon: starkware plans to use poseidon as the main hash function for starknet, and to add a poseidon built-in in cairo. filecoin employs poseidon for merkle tree proofs with different arities and for two-value commitments. dusk network uses poseidon to build a zcash-like protocol for securities trading.11 it also uses poseidon for encryption as described above. sovrin uses poseidon for merkle-tree based revocation. loopring uses poseidon for private trading on ethereum. polygon uses poseidon for hermez zk-evm. in terms of security, the choice of parameters is important. security of the poseidon parameters choice of the mds matrix the mds matrix is a square matrix of size t * t that is used to mix the state. this matrix is used during the mixlayer phase of the poseidon hash function. the matrix must be chosen s.t. no subspace trail with inactive/active s-boxes can be set up for more than t -1 rounds. there are some efficient algorithms to detect weak mds matrices. those algorithms are described in the proving resistance against infinitely long subspace trails: how to choose the linear layer paper. the process of the generation of the matrix should look like this, as recommended in the poseidon paper: generate a random matrix. check if the matrix is secure using algorithm 1, algorithm 2, and algorithm 3 provided proving resistance against infinitely long subspace trails: how to choose the linear layer paper. if the matrix is not secure, go back to step 1. papers and research related to poseidon security poseidon: a new hash function for zero-knowledge proof systems security of the poseidon hash function against non-binary differential and linear attacks report on the security of stark-friendly hash functions practical algebraic attacks against some arithmetization-oriented hash functions copyright copyright and related rights waived via cc0. citation please cite this document as: abdelhamid bakhta (@abdelhamidbakhta), eli ben sasson (@elistark), avihu levy (@avihu28), david levit gurevich (@davidlevitgurevich), "eip-5988: add poseidon hash function precompile [draft]," ethereum improvement proposals, no. 5988, november 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5988. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7496: nft dynamic traits ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7496: nft dynamic traits extension to erc-721 and erc-1155 for dynamic onchain traits authors adam montgomery (@montasaurus), ryan ghods (@ryanio), 0age (@0age), james wenzel (@jameswenzel), stephan min (@stephankmin) created 2023-07-28 discussion link https://ethereum-magicians.org/t/erc-7496-nft-dynamic-traits/15484 requires eip-165, eip-721, eip-1155 table of contents abstract motivation specification keys & names metadata events settrait rationale backwards compatibility test cases reference implementation security considerations copyright abstract this specification introduces a new interface that extends erc-721 and erc-1155 that defines methods for setting and getting dynamic onchain traits associated with non-fungible tokens. these dynamic traits can be used to represent properties, characteristics, redeemable entitlements, or other attributes that can change over time. by defining these traits onchain, they can be used and modified by other onchain contracts. motivation trait values for non-fungible tokens are often stored offchain. this makes it difficult to query and mutate these values in contract code. specifying the ability to set and get traits onchain allows for new use cases like redeeming onchain entitlements and transacting based on a token’s traits. onchain traits can be used by contracts in a variety of different scenarios. for example, a contract that wants to entitle a token to a consumable benefit (e.g. a redeemable) can robustly reflect that onchain. marketplaces can allow bidding on these tokens based on the trait value without having to rely on offchain state and exposing users to frontrunning attacks. the motivating use case behind this proposal is to protect users from frontrunning attacks on marketplaces where users can list nfts with certain traits where they are expected to be upheld during fulfillment. 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. contracts implementing this eip must include the events, getters, and setters as defined below, and must return true for erc-165 supportsinterface for 0xaf332f3e, the 4 byte interfaceid for this erc. interface ierc7496 { /* events */ event traitupdated(bytes32 indexed traitkey, uint256 tokenid, bytes32 traitvalue); event traitupdatedrange(bytes32 indexed traitkey, uint256 fromtokenid, uint256 totokenid); event traitupdatedrangeuniformvalue(bytes32 indexed traitkey, uint256 fromtokenid, uint256 totokenid, bytes32 traitvalue); event traitupdatedlist(bytes32 indexed traitkey, uint256[] tokenids); event traitupdatedlistuniformvalue(bytes32 indexed traitkey, uint256[] tokenids, bytes32 traitvalue); event traitmetadatauriupdated(); /* getters */ function gettraitvalue(uint256 tokenid, bytes32 traitkey) external view returns (bytes32 traitvalue); function gettraitvalues(uint256 tokenid, bytes32[] calldata traitkeys) external view returns (bytes32[] traitvalues); function gettraitmetadatauri() external view returns (string memory uri); /* setters */ function settrait(uint256 tokenid, bytes32 traitkey, bytes32 newvalue) external; } keys & names the traitkey is used to identify a trait. the traitkey must be a unique bytes32 value identifying a single trait. the traitkey should be a keccak256 hash of a human readable trait name. metadata trait metadata is an optional way to define additional information about which traits are present in a contract, how to parse and display trait values, and permissions for setting trait values. the trait metadata must be compliant with the specified schema. the trait metadata uri may be a data uri or point to an offchain resource. the keys in the traits object must be unique trait names. if the trait name is 32 byte hex string starting with 0x then it is interpreted as a literal traitkey. otherwise, the traitkey is defined as the keccak256 hash of the trait name. a literal traitkey must not collide with the keccak256 hash of any other traits defined in the metadata. the displayname values must be unique and must not collide with the displayname of any other traits defined in the metadata. the validateonsale value provides a signal to marketplaces on how to validate the trait value when a token is being sold. if the validation criteria is not met, the sale must not be permitted by the marketplace contract. if specified, the value of validateonsale must be one of the following (or it is assumed to be none): none: no validation is necessary. requireeq: the bytes32 traitvalue must be equal to the value at the time the offer to purchase was made. requireuintgte: the bytes32 traitvalue must be greater than or equal to the value at the time the offer to purchase was made. this comparison is made using the uint256 representation of the bytes32 value. requireuintlte: the bytes32 traitvalue must be less than or equal to the value at the time the offer to purchase was made. this comparison is made using the uint256 representation of the bytes32 value. note that even though this specification requires marketplaces to validate the required trait values, buyers and sellers cannot fully rely on marketplaces to do this and must also take their own precautions to research the current trait values prior to initiating the transaction. here is an example of the specified schema: { "traits": { "color": { "displayname": "color", "datatype": { "type": "string", "acceptablevalues": ["red", "green", "blue"] } }, "points": { "displayname": "total score", "datatype": { "type": "decimal", "signed": false, "decimals": 0 }, "validateonsale": "requireuintgte" }, "name": { "displayname": "name", "datatype": { "type": "string", "minlength": 1, "maxlength": 32, "valuemappings": { "0x0000000000000000000000000000000000000000000000000000000000000000": "unnamed", "0x92e75d5e42b80de937d204558acf69c8ea586a244fe88bc0181323fe3b9e3ebf": "🙂" } }, "tokenownercanupdatevalue": true }, "birthday": { "displayname": "birthday", "datatype": { "type": "epochseconds", "valuemappings": { "0x0000000000000000000000000000000000000000000000000000000000000000": null } } }, "0x77c2fd45bd8bdef5b5bc773f46759bb8d169f3468caab64d7d5f2db16bb867a8": { "displayname": "🚢 📅", "datatype": { "type": "epochseconds", "valuemappings": { "0x0000000000000000000000000000000000000000000000000000000000000000": 1696702201 } } } } } string metadata type the string metadata type allows for a string value to be set for a trait. the datatype object may have a minlength and maxlength value defined. if minlength is not specified, it is assumed to be 0. if maxlength is not specified, it is assumed to be a reasonable length. the datatype object may have a valuemappings object defined. if the valuemappings object is defined, the valuemappings object must be a mapping of bytes32 values to string or unset null values. the bytes32 values should be the keccak256 hash of the string value. the string values must be unique. if the trait for a token is updated to null, it is expected offchain indexers to delete the trait for the token. decimal metadata type the decimal metadata type allows for a numeric value to be set for a trait in decimal form. the datatype object may have a signed value defined. if signed is not specified, it is assumed to be false. this determines whether the traitvalue returned is interpreted as a signed or unsigned integer. the datatype object may have minvalue and maxvalue values defined. these should be formatted with the decimals specified. if minvalue is not specified, it is assumed to be the minimum value of signed and decimals. if maxvalue is not specified, it is assumed to be the maximum value of the signed and decimals. the datatype object may have a decimals value defined. the decimals value must be a non-negative integer. the decimals value determines the number of decimal places included in the traitvalue returned onchain. if decimals is not specified, it is assumed to be 0. the datatype object may have a valuemappings object defined. if the valuemappings object is defined, the valuemappings object must be a mapping of bytes32 values to numeric or unset null values. boolean metadata type the boolean metadata type allows for a boolean value to be set for a trait. the datatype object may have a valuemappings object defined. if the valuemappings object is defined, the valuemappings object must be a mapping of bytes32 values to boolean or unset null values. the boolean values must be unique. if valuemappings is not used, the default trait values for boolean should be bytes32(0) for false and bytes32(uint256(1)) (0x0000000000000000000000000000000000000000000000000000000000000001) for true. epochseconds metadata type the epochseconds metadata type allows for a numeric value to be set for a trait in seconds since the unix epoch. the datatype object may have a valuemappings object defined. if the valuemappings object is defined, the valuemappings object must be a mapping of bytes32 values to integer or unset null values. events updating traits must emit one of: traitupdated traitupdatedrange traitupdatedrangeuniformvalue traitupdatedlist traitupdatedlistuniformvalue for the range events, the fromtokenid and totokenid must be a consecutive range of tokens ids and must be treated as an inclusive range. for the list events, the tokenids may be in any order. it is recommended to use the uniformvalue events when the trait value is uniform across all token ids, so offchain indexers can more quickly process bulk updates rather than fetching each trait value individually. updating the trait metadata must emit the event traitmetadatauriupdated so offchain indexers can be notified to query the contract for the latest changes via gettraitmetadatauri(). settrait if a trait defines tokenownercanupdatevalue as true, then the trait value must be updatable by the token owner by calling settrait. if the value the token owner is attempting to set is not valid, the transaction must revert. if the value is valid, the trait value must be updated and one of the traitupdated events must be emitted. if the trait has a valuemappings entry defined for the desired value being set, settrait must be called with the corresponding traitvalue. rationale the design of this specification is primarily a key-value mapping for maximum flexibility. this interface for traits was chosen instead of relying on using regular getfoo() and setfoo() style functions to allow for brevity in defining, setting, and getting traits. otherwise, contracts would need to know both the getter and setter function selectors including the parameters that go along with it. in defining general but explicit get and set functions, the function signatures are known and only the trait key and values are needed to query and set the values. contracts can also add new traits in the future without needing to modify contract code. the traits metadata allows for customizability of both display and behavior. the valuemappings property can define human-readable values to enhance the traits, for example, the default label of the 0 value (e.g. if the key was “redeemed”, “0” could be mapped to “no”, and “1” to “yes”). the validateonsale property lets the token creator define which traits should be protected on order creation and fulfillment, to protect end users against frontrunning. backwards compatibility as a new eip, no backwards compatibility issues are present, except for the point in the specification above that it is explicitly required that the onchain traits must override any conflicting values specified by the erc-721 or erc-1155 metadata uris. test cases authors have included foundry tests covering functionality of the specification in the assets folder. reference implementation authors have included reference implementations of the specification in the assets folder. security considerations the set* methods exposed externally must be permissioned so they are not callable by everyone but only by select roles or addresses. marketplaces should not trust offchain state of traits as they can be frontrunned. marketplaces should check the current state of onchain traits at the time of transfer. marketplaces may check certain traits that change the value of the nft (e.g. redemption status, defined by metadata values with validateonsale property) or they may hash all the trait values to guarantee the same state at the time of order creation. copyright copyright and related rights waived via cc0. citation please cite this document as: adam montgomery (@montasaurus), ryan ghods (@ryanio), 0age (@0age), james wenzel (@jameswenzel), stephan min (@stephankmin), "erc-7496: nft dynamic traits [draft]," ethereum improvement proposals, no. 7496, july 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7496. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6808: fungible key bound token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-6808: fungible key bound token an interface for fungible key bound tokens, also known as a fkbt. authors mihai onila (@mihaioro), nick zeman (@nickzcz), narcis cotaie (@narciscro) created 2023-03-31 requires eip-20 table of contents abstract motivation specification ikbt20 (token contract) events interface functions rationale backwards compatibility test cases reference implementation security considerations copyright abstract a standard interface for fungible key bound tokens (fkbt/s), a subset of the more general key bound tokens (kbt/s). the following standardizes an api for tokens within smart contracts and provides basic functionality to the addbindings function. this function designates key wallets1, which are responsible for conducting a safe transfer2. during this process, fkbt’s are safely approved so they can be spent by the user or an on-chain third-party entity. the premise of fkbt’s is to provide fully optional security features built directly into the fungible asset, via the concept of allow found in the allowtransfer and allowapproval functions. these functions are called by one of the key wallets1 and allow the holding wallet3 to either call the already familiar transfer and approve function found in erc-20. responsibility for the fkbt is therefore split. the holding wallet contains the asset and key wallets have authority over how the assets can be spent or approved. default behaviors4 of a traditional fungible erc-20 can be achieved by simply never using the addbindings function. we considered fkbts being used by every individual who wishes to add additional security to their fungible assets, as well as consignment to third-party wallets/brokers/banks/insurers. fkbts are resilient to attacks/thefts, by providing additional protection to the asset itself on a self-custodial level. motivation in this fast-paced technologically advancing world, people learn and mature at different speeds. the goal of global adoption must take into consideration the target demographic is of all ages and backgrounds. unfortunately for self-custodial assets, one of the greatest pros is also one of its greatest cons. the individual is solely responsible for their actions and adequately securing their assets. if a mistake is made leading to a loss of funds, no one is able to guarantee their return. from january 2021 through march 2022, the united states federal trade commission received more than 46,0005 crypto scam reports. this directly impacted crypto users and resulted in a net consumer loss exceeding $1 billion6. theft and malicious scams are an issue in any financial sector and oftentimes lead to stricter regulation. however, government-imposed regulation goes against one of this space’s core values. efforts have been made to increase security within the space through centralized and decentralized means. up until now, no one has offered a solution that holds onto the advantages of both whilst eliminating their disadvantages. we asked ourselves the same question as many have in the past, “how does one protect the wallet?”. after a while, realizing the question that should be asked is “how does one protect the asset?”. creating the wallet is free, the asset is what has value and is worth protecting. this question led to the development of kbt’s. a solution that is fully optional and can be tailored so far as the user is concerned. individual assets remain protected even if the seed phrase or private key is publicly released, as long as the security feature was activated. fkbts saw the need to improve on the widely used fungible erc-20 token standard. the security of fungible assets is a topic that concerns every entity in the crypto space, as their current and future use cases are continuously explored. fkbts provide a scalable decentralized security solution that takes security one step beyond wallet security, focusing on the token’s ability to remain secure. the security is on the blockchain itself, which allows every demographic that has access to the internet to secure their assets without the need for current hardware or centralized solutions. made to be a promising alternative, fkbts inherit all the characteristics of an erc-20. this was done so fkbts could be used on every dapp that is configured to use traditional fungible tokens. during the development process, the potential advantages kbt’s explored were the main motivation factors leading to their creation; completely decentralized: the security features are fully decentralized meaning no third-party will have access to user funds when activated. this was done to truly stay in line with the premise of self-custodial assets, responsibility and values. limitless scalability: centralized solutions require the creation of an account and their availability may be restricted based on location. fkbt’s do not face regional restrictions or account creation. decentralized security solutions such as hardware options face scalability issues requiring transport logistics, secure shipping and vendor. fkbt’s can be used anywhere around the world by anyone who so wishes, provided they have access to the internet. fully optional security: security features are optional, customizable and removable. it’s completely up to the user to decide the level of security they would like when using fkbt’s. default functionality: if the user would like to use fkbt’s as a traditional erc-20, the security features do not have to be activated. as the token inherits all of the same characteristics, it results in the token acting with traditional fungible default behaviors4. however, even when the security features are activated, the user will still have the ability to customize the functionality of the various features based on their desired outcome. the user can pass a set of custom and or default values7 manually or through a dapp. unmatched security: by calling the addbindings function a key wallet1 is now required for the allowtransfer or allowapproval function. the allowtransfer function requires 4 parameters, _amount8, _time9, _address10, and _allfunds11, where as the allowapproval function has 2 parameters, _time12 and _numberoftransfers13. in addition to this, fkbt’s have a safefallback and resetbindings function. the combination of all these prevent and virtually cover every single point of failure that is present with a traditional erc-20, when properly used. security fail-safes: with fkbts, users can be confident that their tokens are safe and secure, even if the holding wallet3 or one of the key wallets1 has been compromised. if the owner suspects that the holding wallet has been compromised or lost access, they can call the safefallback function from one of the key wallets. this moves the assets to the other key wallet preventing a single point of failure. if the owner suspects that one of the key wallets has been comprised or lost access, the owner can call the resetbindings function from _keywallet114 or _keywallet215. this resets the fkbt’s security feature and allows the holding wallet to call the addbindings function again. new key wallets can therefore be added and a single point of failure can be prevented. anonymous security: frequently, centralized solutions ask for personal information that is stored and subject to prying eyes. purchasing decentralized hardware solutions are susceptible to the same issues e.g. a shipping address, payment information, or a camera recording during a physical cash pick-up. this may be considered by some as infringing on their privacy and asset anonymity. fkbt’s ensure user confidentially as everything can be done remotely under a pseudonym on the blockchain. low-cost security: the cost of using fkbt’s security features correlate to on-chain fees, the current gwei at the given time. as a standalone solution, they are a viable cost-effective security measure feasible to the majority of the population. environmentally friendly: since the security features are coded into the fkbt, there is no need for centralized servers, shipping, or the production of physical object/s. thus leading to a minimal carbon footprint by the use of fkbt’s, working hand in hand with ethereum’s change to a pos16 network. user experience: the security feature can be activated by a simple call to the addbindings function. the user will only need two other wallets, which will act as _keywallet114 and _keywallet215, to gain access to all of the benefits fkbt’s offer. the optional security features improve the overall user experience and ethereum ecosystem by ensuring a safety net for those who decide to use it. those that do not use the security features are not hindered in any way. this safety net can increase global adoption as people can remain confident in the security of their assets, even in the scenario of a compromised wallet. specification ikbt20 (token contract) notes: the following specifications use syntax from solidity 0.8.0 (or above) callers must handle false from returns (bool success). callers must not assume that false is never returned! interface ikbt20 { event accountsecured(address _account, uint256 _amount); event accountresetbinding(address _account); event safefallbackactivated(address _account); event accountenabledtransfer( address _account, uint256 _amount, uint256 _time, address _to, bool _allfunds ); event accountenabledapproval( address _account, uint256 _time, uint256 _numberoftransfers ); event ingress(address _account, uint256 _amount); event egress(address _account, uint256 _amount); struct accountholderbindings { address firstwallet; address secondwallet; } struct firstaccountbindings { address accountholderwallet; address secondwallet; } struct secondaccountbindings { address accountholderwallet; address firstwallet; } struct transferconditions { uint256 amount; uint256 time; address to; bool allfunds; } struct approvalconditions { uint256 time; uint256 numberoftransfers; } function addbindings( address _keywallet1, address _keywallet2 ) external returns (bool); function getbindings( address _account ) external view returns (accountholderbindings memory); function resetbindings() external returns (bool); function safefallback() external returns (bool); function allowtransfer( uint256 _amount, uint256 _time, address _to, bool _allfunds ) external returns (bool); function gettransferablefunds( address _account ) external view returns (transferconditions memory); function allowapproval( uint256 _time, uint256 _numberoftransfers ) external returns (bool); function getapprovalconditions( address account ) external view returns (approvalconditions memory); function getnumberoftransfersallowed( address _account, address _spender ) external view returns (uint256); function issecurewallet(address _account) external view returns (bool); } events accountsecured event emitted when the _account is securing his account by calling the addbindings function. _amount is the current balance of the _account. event accountsecured(address _account, uint256 _amount) accountresetbinding event emitted when the holder is resetting his keywallets by calling the resetbindings function. event accountresetbinding(address _account) safefallbackactivated event emitted when the holder is choosing to move all the funds to one of the keywallets by calling the safefallback function. event safefallbackactivated(address _account) accountenabledtransfer event emitted when the _account has allowed for transfer an _amount of tokens for the _time amount of block seconds for _to address (or if the _account has allowed for transfer all funds though _allfunds set to true) by calling the allowtransfer function. event accountenabledtransfer(address _account, uint256 _amount, uint256 _time, address _to, bool _allfunds) accountenabledapproval event emitted when _account has allowed approval, for the _time amount of block seconds and set a _numberoftransfers allowed, by calling the allowapproval function. event accountenabledapproval(address _account, uint256 _time, uint256 _numberoftransfers) ingress event emitted when _account becomes a holder. _amount is the current balance of the _account. event ingress(address _account, uint256 _amount) egress event emitted when _account transfers all his tokens and is no longer a holder. _amount is the previous balance of the _account. event egress(address _account, uint256 _amount) interface functions the functions detailed below must be implemented. addbindings function secures the sender account with other two wallets called _keywallet1 and _keywallet2 and must fire the accountsecured event. the function should revert if: the sender account is not a holder or the sender is already secured or the keywallets are the same or one of the keywallets is the same as the sender or one or both keywallets are zero address (0x0) or one or both keywallets are already keywallets to another holder account function addbindings (address _keywallet1, address _keywallet2) external returns (bool) getbindings function the function returns the keywallets for the _account in a struct format. struct accountholderbindings { address firstwallet; address secondwallet; } function getbindings(address _account) external view returns (accountholderbindings memory) resetbindings function note: this function is helpful when one of the two keywallets is compromised. called from a keywallet, the function resets the keywallets for the holder account. must fire the accountresetbinding event. the function should revert if the sender is not a keywallet. function resetbindings() external returns (bool) safefallback function note: this function is helpful when the holder account is compromised. called from a keywallet, this function transfers all the tokens from the holder account to the other keywallet and must fire the safefallbackactivated event. the function should revert if the sender is not a keywallet. function safefallback() external returns (bool); allowtransfer function called from a keywallet, this function is called before a transfer function is called. it allows to transfer a maximum amount, for a specific time frame, to a specific address. if the amount is 0 then there will be no restriction on the amount. if the time is 0 then there will be no restriction on the time. if the to address is zero address then there will be no restriction on the to address. or if _allfunds is true, regardless of the other params, it allows all funds, whenever, to anyone to be transferred. the function must fire accountenabledtransfer event. the function should revert if the sender is not a keywallet or if the _amount is greater than the holder account balance. function allowtransfer(uint256 _amount, uint256 _time, address _to, bool _allfunds) external returns (bool); gettransferablefunds function the function returns the transfer conditions for the _account in a struct format. struct transferconditions { uint256 amount; uint256 time; address to; bool allfunds; } function gettransferablefunds(address _account) external view returns (transferconditions memory); allowapproval function called from a keywallet, this function is called before one of the approve, increaseallowance or decreaseallowance function are called. it allows the holder for a specific amount of _time to do an approve, increaseallowance or decreaseallowance and limit the number of transfers the spender is allowed to do through _numberoftransfers (0 unlimited number of transfers in the allowance limit). the function must fire accountenabledapproval event. the function should revert if the sender is not a keywallet. function allowapproval(uint256 _time, uint256 _numberoftransfers) external returns (bool) getapprovalconditions function the function returns the approval conditions in a struct format. where time is the block.timestamp until the approve, increaseallowance or decreaseallowance functions can be called, and numberoftransfers is the number of transfers the spender will be allowed. struct approvalconditions { uint256 time; uint256 numberoftransfers; } function getapprovalconditions(address _account) external view returns (approvalconditions memory); transfer function the function transfers _amount of tokens to address _to. the function must fire the transfer event. the function should revert if the sender’s account balance does not have enough tokens to spend, or if the sender is a secure account and it has not allowed the transfer of funds through allowtransfer function. note: transfers of 0 values must be treated as normal transfers and fire the transfer event. function transfer(address _to, uint256 _amount) external returns (bool) approve function the function allows _spender to transfer from the holder account multiple times, up to the _value amount. the function also limits the _spender to the specific number of transfers set in the approvalconditions for that holder account. if the value is 0 then the _spender can transfer multiple times, up to the _value amount. the function must fire an approval event. if this function is called again it overrides the current allowance with _value and also overrides the number of transfers allowed with _numberoftransfers, set in allowapproval function. the function should revert if: the sender account is secured and has not called allowapproval function or if the _time, set in the allowapproval function, has elapsed. function approve(address _spender, uint256 _amount) external returns (bool) increaseallowance function the function increases the allowance granted to _spender to withdraw from your account. the function emits an approval event indicating the updated allowance. the function should revert if: the sender account is secured and has not called allowapproval function or if the _spender is a zero address (0x0) or if the _time, set in the allowapproval function, has elapsed. function increaseallowance(address _spender, uint256 _addedvalue) external returns (bool) decreaseallowance function the function decreases the allowance granted to _spender to withdraw from your account. the function emits an approval event indicating the updated allowance. the function should revert if: the sender account is secured and has not called allowapproval function or if the _spender is a zero address (0x0) or if the _time, set in the allowapproval function, has elapsed. or if the _subtractedvalue is greater than the current allowance function decreaseallowance(address _spender, uint256 _subtractedvalue) external returns (bool) transferfrom function the function transfers _amount of tokens from address _from to address _to. the function must fire the transfer event. the transferfrom method is used for a withdraw workflow, allowing contracts to transfer tokens on your behalf. the function should revert unless the _from account has deliberately authorized the sender. each time the spender calls the function the contract subtracts and checks if the number of allowed transfers has reached 0, and when that happens the approval is revoked using an approve of 0 amount. note: transfers of 0 values must be treated as normal transfers and fire the transfer event. function transferfrom(address _from, address _to, uint256 _amount) external returns (bool) rationale the intent from individual technical decisions made during the development of fkbts focused on maintaining consistency and backward compatibility with erc-20s, all the while offering self-custodial security features to the user. it was important that fkbt’s inherited all of erc-20s characteristics to comply with requirements found in dapps which use fungible tokens on their platform. in doing so, it allowed for flawless backward compatibility to take place and gave the user the choice to decide if they want their fkbts to act with default behaviors4. we wanted to ensure that wide-scale implementation and adoption of fkbts could take place immediately, without the greater collective needing to adapt and make changes to the already flourishing decentralized ecosystem. for developers and users alike, the allowtransfer and allowapproval functions both return bools on success and revert on failures. this decision was done purposefully, to keep consistency with the already familiar erc-20. additional technical decisions related to self-custodial security features are broken down and located within the security considerations section. backwards compatibility kbt’s are designed to be backward-compatible with existing token standards and wallets. existing tokens and wallets will continue to function as normal, and will not be affected by the implementation of fkbt’s. test cases the assets directory has all the tests. average gas used (gwei): addbindings 154,991 resetbindings 30,534 safefallback 51,013 allowtransfer 49,887 allowapproval 44,971 reference implementation the implementation is located in the assets directory. there’s also a diagram with the contract interactions. security considerations fkbt’s were designed with security in mind every step of the way. below are some design decisions that were rigorously discussed and thought through during the development process. key wallets1: when calling the addbindings function for an fkbt, the user must input 2 wallets that will then act as _keywallet114 and _keywallet215. they are added simultaneously to reduce user fees, minimize the chance of human error and prevent a pitfall scenario. if the user had the ability to add multiple wallets it would not only result in additional fees and avoidable confusion but would enable a potentially disastrous safefallback situation to occur. for this reason, all kbt’s work under a 3-wallet system when security features are activated. typically if a wallet is compromised, the fungible assets within are at risk. with fkbt’s there are two different functions that can be called from a key wallet1 depending on which wallet has been compromised. scenario: holding wallet3 has been compromised, call safefallback. safefallback: this function was created in the event that the owner believes the holding wallet3 has been compromised. it can also be used if the owner losses access to the holding wallet. in this scenario, the user has the ability to call safefallback from one of the key wallets1. fkbt’s are then redirected from the holding wallet to the other key wallet. by redirecting the fkbt’s it prevents a single point of failure. if an attacker were to call safefallback and the fkbt’s redirected to the key wallet1 that called the function, they would gain access to all the fkbt’s. scenario: key wallet1 has been compromised, call resetbindings. resetbindings: this function was created in the event that the owner believes _keywallet114 or _keywallet215 has been compromised. it can also be used if the owner losses access to one of the key wallets1. in this instance, the user has the ability to call resetbindings, removing the bound key wallets and resetting the security features. the fkbt’s will now function as a traditional erc-20 until addbindings is called again and a new set of key wallets are added. the reason why _keywallet114 or _keywallet215 are required to call the resetbindings function is because a holding wallet3 having the ability to call resetbindings could result in an immediate loss of fkbt’s. the attacker would only need to gain access to the holding wallet and call resetbindings. in the scenario that 2 of the 3 wallets have been compromised, there is nothing the owner of the fkbt’s can do if the attack is malicious. however, by allowing 1 wallet to be compromised, holders of fungible tokens built using the fkbt standard are given a second chance, unlike other current standards. the allowtransfer function is in place to guarantee a safe transfer2, but can also have default values7 set by a dapp to emulate default behaviors3 of a traditional erc-20. it enables the user to highly specify the type of transfer they are about to conduct, whilst simultaneously allowing the user to unlock all the fkbt’s to anyone for an unlimited amount of time. the desired security is completely up to the user. this function requires 4 parameters to be filled and different combinations of these result in different levels of security; parameter 1 _amount8: this is the number of fkbt’s that will be spent on a transfer. parameter 2 _time9: the number of blocks the fkbt’s can be transferred starting from the current block timestamp. parameter 3 _address10: the destination the fkbt’s will be sent to. parameter 4 _allfunds11: this is a boolean value. when false, the transfer function takes into consideration parameters 1, 2 and 3. if the value is true, the transfer function will revert to a default behavior4, the same as a traditional erc-20. the allowtransfer function requires _keywallet114 or _keywallet215 and enables the holding wallet3 to conduct a transfer within the previously specified parameters. these parameters were added in order to provide additional security by limiting the holding wallet in case it was compromised without the user’s knowledge. the allowapproval function provides extra security when allowing on-chain third parties to use your fkbt’s on your behalf. this is especially useful when a user is met with common malicious attacks e.g. draining dapp. this function requires 2 parameters to be filled and different combinations of these result in different levels of security; parameter 1 _time12: the number of blocks that the approval of a third-party service can take place, starting from the current block timestamp. parameter 2 _numberoftransfers_13: the number of transactions a third-party service can conduct on the user’s behalf. the allowapproval function requires _keywallet114 or _keywallet215 and enables the holding wallet3 to allow a third-party service by using the approve function. these parameters were added to provide extra security when granting permission to a third-party that uses assets on the user’s behalf. parameter 1, _time12, is a limitation to when the holding wallet can approve a third-party service. parameter 2, _numberoftransfers13, is a limitation to the number of transactions the approved third-party service can conduct on the user’s behalf before revoking approval. copyright copyright and related rights waived via cc0. the key wallet/s refers to _keywallet1 or _keywallet2 which can call the safefallback, resetbindings, allowtransfer and allowapproval functions. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 a safe transfer is when 1 of the key wallets safely approved the use of the fkbt’s. ↩ ↩2 the holding wallet refers to the wallet containing the fkbt’s. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 a default behavior/s refers to behavior/s present in the preexisting non-fungible erc-20 standard. ↩ ↩2 ↩3 ↩4 the number of crypto scam reports the united states federal trade commission received, from january 2021 through march 2022. ↩ the amount stolen via crypto scams according to the united states federal trade commission, from january 2021 through march 2022. ↩ a default value/s refer to a value/s that emulates the non-fungible erc-20 default behavior/s. ↩ ↩2 the _amount represents the amount of the fkbt’s intended to be spent. ↩ ↩2 the _time in allowtransfer represents the number of blocks a transfer can take place in. ↩ ↩2 the _address represents the address that the fkbt’s will be sent to. ↩ ↩2 the _allfunds is a bool that can be set to true or false. ↩ ↩2 the _time in allowapproval represents the number of blocks an approve can take place in. ↩ ↩2 ↩3 the _numberoftransfers is the number of transfers a third-party entity can conduct via transfer on the user’s behalf. ↩ ↩2 ↩3 the _keywallet1 is 1 of the 2 key wallets set when calling the addbindings function. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 the _keywallet2 is 1 of the 2 key wallets set when calling the addbindings function. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 a pos protocol, proof-of-stake protocol, is a cryptocurrency consensus mechanism for processing transactions and creating new blocks in a blockchain. ↩ citation please cite this document as: mihai onila (@mihaioro), nick zeman (@nickzcz), narcis cotaie (@narciscro), "erc-6808: fungible key bound token," ethereum improvement proposals, no. 6808, march 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6808. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3416: median gas premium ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-3416: median gas premium authors hexzorro (@hexzorro), mojtaba tefagh (@mtefagh) created 2021-03-18 discussion link https://ethereum-magicians.org/t/eip-3416-median-gas-premium/5755 table of contents simple summary abstract motivation specification definitions process rationale backwards compatibility test cases security considerations copyright simple summary a transaction pricing mechanism with a fixed-per-block network fee and a median inclusion fee with additive updates. abstract there is a base fee per gas in protocol, which can move up or down by a maximum of 1/8 in each block. the base fee per gas is adjusted by the protocol to target an average gas usage per block instead of an absolute gas usage per block. the base fee is increased when blocks are over the gas limit target and decreases when blocks are under the gas limit target. transaction senders specify their fees by providing only one value: the fee cap which represents the maximum total (base fee + gas premium) that the transaction sender would be willing to pay to get their transaction included, resembles the current maximum gas price specified by senders but in this protocol change proposal the final gas price paid, most of the time, will be lower than the proposed by the transaction sender. then there is a gas premium that is directly computed as 50% of (fee cap base fee). this gas premium gets added onto the base fee to calculate the gas price that will be used in the weighted median computation. the gas premium, determined directly by a specified fee cap, can either be set to a fairly low value to compensate miners for uncle rate risk only with the base fee, or to a high value to compete during sudden bursts of activity. using all transactions that the miner wants to include in the block, a weighted median gas premium is computed, not considering in the computation 5% of gas price outliers on the upper-side for extra robustness against miner manipulation. motivation we target the following goals: gas prices spikes are mathematically smoothed out. eip1559 does not seems to really tackle gas premium volatility and ux. maintain gas price preference, i.e. transaction senders willing to pay extra in fees will be rewarded with early preferential inclusion in the blocks, because the miners want to maximize their profits and include transactions with higher fee caps first to maximize the median. final gas price paid by the sender is, most of the time, smaller than the maximum gas price specified by sender. gas pricing is more robust to sender manipulation or miner manipulation. ethereum currently prices transaction fees using a simple auction mechanism, where users send transactions with bids (“gasprices”) and miners choose transactions with the highest bids, and transactions that get included pay the bid that they specify. this leads to several large sources of inefficiency: current extreme volatility of gas prices is hurting user experience: if you observe online gas price metrics, the current trends in recommended gas prices can change substantially by the minute, making the user experience in the network very awkward. also, gas volatility makes the mining business more unpredictable and costly, because miners need to spend money hedging the risks. mismatch between volatility of transaction fee levels and social cost of transactions: bids to include transactions on mature public blockchains, that have enough usage so that blocks are full, tend to be extremely volatile. on ethereum, minimum bids range between 1 nanoeth (10^9 nanoeth = 1 eth), but sometimes go over 100 nanoeth and have reached over 200 nanoeth. this clearly creates many inefficiencies, because it’s absurd to suggest that the cost incurred by the network from accepting one more transaction into a block actually is 200x more when gas prices are 200 nanoeth than when they are 1 nanoeth; in both cases, it’s a difference between 8 million gas and 8.02 million gas. needless delays for users: because of the hard per-block gas limit coupled with natural volatility in transaction volume, transactions often wait for several blocks before getting included, but this is socially unproductive; no one significantly gains from the fact that there is no “slack” mechanism that allows one block to be bigger and the next block to be smaller to meet block-by-block differences in demand. inefficiencies of first price auctions: the current approach, where transaction senders publish a transaction with a bid a maximum fee, miners choose the highest-paying transactions, and everyone pays what they bid. this is well-known in mechanism design literature to be highly inefficient, and so complex fee estimation algorithms are required. but even these algorithms often end up not working very well, leading to frequent fee overpayment. we need a more stable fee metric that is computed inside the protocol. the proposal in this eip is to start with a base fee amount which is adjusted up and down by the protocol based on how congested the network is. when the network exceeds the target per-block gas usage, the base fee increases slightly and when capacity is below the target, it decreases slightly. because these base fee changes are constrained, the maximum difference in base fee from block to block is predictable. this then allows wallets to auto-set the gas fees for users in a highly reliable fashion. it is expected that most users will not have to manually adjust gas fees, even in periods of high network activity. for most users the base fee will be estimated by their wallet and a small gas premium related to the urgency and the priority they want to instill into the transaction. specification definitions this is a classic fork without a long migration time. fork_block_number: tbd. block number at or after which eip-3416 transactions are valid. gas_target_max_change: 1 // 1024. block_gas_used: total gas consumed by transaction included in the block. parent_gas_used: same as block_gas_used for parent block. current_block: the current block that is being worked with (either being validated, or being produced). base_fee: 16th item in the block header. represents the amount of attoeth burned for every unit of gas a transaction uses. parent_base_fee: same as base_fee for parent block. base_fee_max_change: 1 // 8 initial_base_fee : median gas price in fork_block_number 1. process at block.number == fork_block_number we set base_fee = initial_base_fee base_fee is set, from fork_block_number + 1, as follows let gas_delta = (parent_gas_used parent_gas_target) // parent_gas_target (possibly negative). set base_fee = parent_base_fee + gsa_delta * base_fee_max_change transactions since fork_block_number are encoded the same as the current ones rlp([nonce, gasprice, gaslimit, to, value, data, v, r, s]) where v,r,s is a signature of rlp([nonce, gasprice, gaslimit, to, value, data]) and gasprice is the fee_cap specified by the sender according to this proposal. to produce transactions since fork_block_number, the new fee_cap field (maintaining legacy name of gasprice in the transaction) is set as follows (and the gas_premium is computed as specified): fee_cap: tx.gasprice, serves as the absolute maximum that the transaction sender is willing to pay. gas_premium = (fee_cap base_fee) / 2 serves as a sender-preferred median premium to the miner, beyond the base fee. if fee_cap < base_fee then the transaction is considered invalid and cannot be included in the current block, but might be included in future blocks. during transaction execution, for eip3416 transactions we calculate the cost to the tx.origin and the gain to the block.coinbase as follows: set gasprice = base_fee + median((tx_i.gasprice base_fee) / 2) among all transactions tx_i included in the same block, weighted by gas consumed and not including the top 5% of outlier gas price in calculation. by weighted median without 5% of the upper-side outliers, we mean that each gas unit spent is ordered according to the corresponding transaction by base_fee + tx.gasprice / 2 and then the value chosen will be the one separating the lower 95% in two parts. let gasused be the gas used during the transaction execution/state transition. the tx.origin initially pays gasprice * tx.gaslimit, and gets refunded gasprice * (tx.gaslimit gasused). the miners can still use a greedy strategy to include new transactions in the proposed blocks by adding the transactions ordered by larger fee_cap first. this is similar to how current blocks are filled, and is a consequence of fee_cap and gas_premium being a positive linear function of each other. rationale the rationale behind the premium being 50% of (fee cap base fee) is that at any given point the average network sender has an average fee cap, and we assume that between base fee and fee cap the sender has no specific preference, as long as the transaction is included in some block. then, the sender is happy with a median premium among this uniform range. another justification can be that the user also knows that this new version of the pricing protocol for the complete block uses a median, then is fair for him to apply a median within his preferential range, assuming an uniform sampling there. simulations (here) with ethereum gas data shows indeed that median one of the most robust metric.s the 5% top outliers removal, not considered in the median, or similar number, is to give extra robustness against miner manipulation, because as current network utilization has been around 97% for the last 6 months the miners can include their own transactions on the empty 3% to try to manipulate and increase the median price (even this manipulation effect will be very small on the final price). the rationale for the base_fee update formula is that we are using an additive version (parent_base_fee + gas_delta * base_fee_max_change) to avoid an attack of senders sending this fee to zero. this attack was simulated and observed for multiplicative formula proposed in previous version (parent_base_fee + parent_base_fee * gas_delta * base_fee_max_change). see an article about the attack and the simulation here. another rationale for the additive base_fee update formula is that it guarantees (see this article) that the optimal execution strategy (scheduling broadcasts in order to pay less fee) for a batch of nonurgent transactions is to spread the transactions across different blocks which in turn helps to avoid network congestion and lowers volatility. for the multiplicative formula, it is exactly the reverse, that is, spikes (dumping all your transactions at once) are incentivized as described here. the rationale for the base_fee_max_change being 1 // 8 is that the base_fee is designed to be very adaptative to block utilization changes. backwards compatibility the backward compatibility is very straightforward because there are no new fields added to the transactions. pricing of the gas per block on the miner/validator side is still fast to compute but a little more complex. changes only affect miners/validators. wallets are no affected by this proposal. test cases tbd. security considerations senders cannot manipulate the minimum fee because the minimum base_fee is controlled by the miners with small increments or decrements on each new block proposed. above the base_fee the senders have a very limited ability to manipulate and lower the final gas price they pay because they have to move the weighted median close to base_fee and, as we know, this is a very robust statistic. miners have a very limited ability to manipulate and raise the final gas price paid by senders above base_fee because to influence the final gas price they have to stuff fake transactions beyond the top 5% of the blocks. in average and currently, only the top 3% of the block is empty, so to fill-up 5% of the block they need to start dropping profitable transactions to reach 5%. only beyond 5% of the top block gas they can start moving the median a little and the median is still a very robust statistic, not liable to being easily manipulated. copyright copyright and related rights waived via cc0. citation please cite this document as: hexzorro (@hexzorro), mojtaba tefagh (@mtefagh), "eip-3416: median gas premium [draft]," ethereum improvement proposals, no. 3416, march 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3416. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5516: soulbound multi-owner tokens ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5516: soulbound multi-owner tokens an interface for non-transferable, multi-owner nfts binding to ethereum accounts authors lucas martín grasso ramos (@lucasgrasso), matias arazi (@matiarazi) created 2022-08-19 discussion link https://ethereum-magicians.org/t/eip-5516-soulbound-multi-token-standard/10485 requires eip-165, eip-1155 table of contents abstract motivation characteristics applications specification rationale sbt as an extension of eip-1155 double-signature metadata. guaranteed log trace exception handling multi-token the batchtransfer function backwards compatibility reference implementation security considerations copyright abstract this eip proposes a standard interface for non-fungible double signature soulbound multi-tokens. previous account-bound token standards face the issue of users losing their account keys or having them rotated, thereby losing their tokens in the process. this eip provides a solution to this issue that allows for the recycling of sbts. motivation this eip was inspired by the main characteristics of the eip-1155 token and by articles in which benefits and potential use cases of soulbound/accountbound tokens (sbts) were presented. this design also allows for batch token transfers, saving on transaction costs. trading of multiple tokens can be built on top of this standard and it removes the need to approve individual token contracts separately. it is also easy to describe and mix multiple fungible or non-fungible token types in a single contract. characteristics the nft will be non-transferable after the initial transfer partially compatible with eip-1155 double signature multi-token multi-owner semi-fungible applications academic degrees code audits poaps (proof of attendance protocol nfts) specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. smart contracts implementing this eip must implement all of the functions in the eip-5516 interface. smart contracts implementing this eip must implement the eip-165 supportsinterface function and and must return the constant value true if 0x8314f22b is passed through the interfaceid argument. they also must implement the eip-1155 interface and must return the constant value true if 0xd9b67a26 is passed through the interfaceid argument. furthermore, they must implement the eip-1155 metadata interface, and must return the constant value true if 0x0e89341c is passed through the interfaceid argument. see eip-1155 // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.4; /** @title soulbound, multi-token standard. @notice interface of the eip-5516 note: the erc-165 identifier for this interface is 0x8314f22b. */ interface ierc5516 { /** * @dev emitted when `account` claims or rejects pending tokens under `ids[]`. */ event tokenclaimed( address indexed operator, address indexed account, bool[] actions, uint256[] ids ); /** * @dev emitted when `from` transfers token under `id` to every address at `to[]`. */ event transfermulti( address indexed operator, address indexed from, address[] to, uint256 amount, uint256 id ); /** * @dev get tokens owned by a given address. */ function tokensfrom(address from) external view returns (uint256[] memory); /** * @dev get tokens awaiting to be claimed by a given address. */ function pendingfrom(address from) external view returns (uint256[] memory); /** * @dev claims or reject pending `id`. * * requirements: * `account` must have a pending token under `id` at the moment of call. * `account` must not own a token under `id` at the moment of call. * * emits a {tokenclaimed} event. * */ function claimorreject( address account, uint256 id, bool action ) external; /** * @dev claims or reject pending tokens under `ids[]`. * * requirements for each `id` `action` pair: * `account` must have a pending token under `id` at the moment of call. * `account` must not own a token under `id` at the moment of call. * * emits a {tokenclaimed} event. * */ function claimorrejectbatch( address account, uint256[] memory ids, bool[] memory actions ) external; /** * @dev transfers `id` token from `from` to every address at `to[]`. * * requirements: * * `from` must be the creator(minter) of `id`. * all addresses in `to[]` must be non-zero. * all addresses in `to[]` must have the token `id` under `_pendings`. * all addresses in `to[]` must not own a token type under `id`. * * emits a {transfersmulti} event. * */ function batchtransfer( address from, address[] memory to, uint256 id, uint256 amount, bytes memory data ) external; } rationale sbt as an extension of eip-1155 we believe that soulbound tokens serve as a specialized subset of existing eip-1155 tokens. the advantage of such a design is the seamless compatibility of sbts with existing nft services. service providers can treat sbts like nfts and do not need to make drastic changes to their existing codebase. making the standard mostly compatible with eip-1155 also allows for sbts to bind to multiple addresses and to smart contracts. double-signature the double-signature functionality was implemented to prevent the receipt of unwanted tokens. it symbolizes a handshake between the token receiver and sender, implying that both parties agree on the token transfer. metadata. the eip-1155 metadata interface was implemented for further compatibility with eip-1155. guaranteed log trace as the ethereum ecosystem continues to grow, many dapps are relying on traditional databases and explorer api services to retrieve and categorize data. the eip-1155 standard guarantees that event logs emitted by the smart contract will provide enough data to create an accurate record of all current token balances. a database or explorer may listen to events and be able to provide indexed and categorized searches of every eip-1155 token in the contract. quoted from eip-1155 this eip extends this concept to the double signature functionality: the {tokenclaimed} event logs all the necessary information of a claimorreject(...) or claimorrejectbatch(...) function call, storing relevant information about the actions performed by the user. this also applies to the batchtransfer(...) function: it emits the {transfermulti} event and logs necessary data. exception handling given the non-transferability property of sbts, if a user’s keys to an account get compromised or rotated, such user may lose the ability to associate themselves with the token. given the multi-owner characteristic of eip-1155 compliant interfaces and contracts, sbts will be able to bind to multiple accounts, providing a potential solution to the issue. multi-owner sbts can also be issued to a contract account that implements a multi-signature functionality (as recommended in eip-4973); this can be achieved via the eip-1155 token receiver interface. multi-token the multi-token functionality permits the implementation of multiple token types in the same contract. furthermore, all emitted tokens are stored in the same contract, preventing redundant bytecode from being deployed to the blockchain. it also facilitates transfer to token issuers, since all issued tokens are stored and can be accessed under the same contract address. the batchtransfer function this eip supports transfers to multiple recipients. this eases token transfer to a large number of addresses, making it more gas-efficient and user-friendly. backwards compatibility this proposal is only partially compatible with eip-1155, because it makes tokens non-transferable after the first transfer. reference implementation you can find an implementation of this standard in ../assets/eip-5516. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: lucas martín grasso ramos (@lucasgrasso), matias arazi (@matiarazi), "erc-5516: soulbound multi-owner tokens [draft]," ethereum improvement proposals, no. 5516, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5516. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5478: create2copy opcode ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-5478: create2copy opcode reducing the gas cost of contract creation with existing code authors qi zhou (@qizhou) created 2022-08-17 discussion link https://ethereum-magicians.org/t/eip-5478-reducing-the-gas-cost-of-contract-creation-with-existing-code/10419 requires eip-1014, eip-2929 table of contents abstract motivation specification parameters rationale security considerations copyright abstract adding a new opcode, create2copy, that is identical to create2 but with potentially much lower gas cost by accepting an additional argument existing_contract_address that already stored the code of the new contract. motivation this eip aims to reduce the smart contract creation cost of account abstraction (aa) contracts that have identical code. the major cost of creating an aa contract is the contract creation cost, especially data gas. for example, creating an aa contract with 10,000 bytes will consume 2,000,000 data gas. considering the code for each user’s aa contract is the same, create2copy can reduce the data gas cost to 2600 (cold account) or even 100 (warm account) if the contract code already exists in the local storage. specification parameters constant value fork_blknum tbd create_data_gas_per_byte 200 cold_account_access_cost 2600 warm_account_access_cost 100 if block.number >= fork_blknum, a new opcode is added (create2copy) at 0xf6, which takes 5 stack arguments: endowment, memory_start, memory_length, salt, existing_contract_address. create2copy behaves identically to create2 (0xf5 as defined in eip-1014), except that the code hash of the creating contract must be the same as that of existing_contract_address. create2copy has the same gas schema as create2, but replacing the data gas from create_data_gas_per_byte * contract_bytes to the gas cost of extcodehash opcode, which is cold_account_access_cost if the existing_contract_address is first-time accessed in the transaction or warm_account_access_cost if existing_contract_address is already in the access list according to eip-2929. if the code of the contract returned from the init code differs from that of existing_contract_address, the creation fails with the error “mismatched contract creation code with existing code”, and will burn all gas for the contract creation. rationale tbd security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: qi zhou (@qizhou), "eip-5478: create2copy opcode [draft]," ethereum improvement proposals, no. 5478, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5478. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5646: token state fingerprint ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-5646: token state fingerprint unambiguous token state identifier authors naim ashhab (@ashhanai) created 2022-09-11 requires eip-165 table of contents abstract motivation specification rationale backwards compatibility reference implementation security considerations copyright abstract this specification defines the minimum interface required to unambiguously identify the state of a mutable token without knowledge of implementation details. motivation currently, protocols need to know about tokens’ state properties to create the unambiguous identifier. unfortunately, this leads to an obvious bottleneck in which protocols need to support every new token specifically. specification the key words “must”, “must not”, “should”, “should not”, and “may” in this document are to be interpreted as described in rfc 2119. pragma solidity ^0.8.0; interface erc5646 is erc165 { /// @notice function to return current token state fingerprint. /// @param tokenid id of a token state in question. /// @return current token state fingerprint. function getstatefingerprint(uint256 tokenid) external view returns (bytes32); } getstatefingerprint must return a different value when the token state changes. getstatefingerprint must not return a different value when the token state remains the same. getstatefingerprint must include all state properties that might change during the token lifecycle (are not immutable). getstatefingerprint may include computed values, such as values based on a current timestamp (e.g., expiration, maturity). getstatefingerprint may include token metadata uri. supportsinterface(0xf5112315) must return true. rationale protocols can use state fingerprints as a part of a token identifier and support mutable tokens without knowing any state implementation details. state fingerprints don’t have to factor in state properties that are immutable, because they can be safely identified by a token id. this standard is not for use cases where token state property knowledge is required, as these cases cannot escape the bottleneck problem described earlier. backwards compatibility this eip is not introducing any backward incompatibilities. reference implementation pragma solidity ^0.8.0; /// @title example of a mutable token implementing state fingerprint. contract lptoken is erc721, erc5646 { /// @dev stored token states (token id => state). mapping (uint256 => state) internal states; struct state { address asset1; address asset2; uint256 amount1; uint256 amount2; uint256 fee; // immutable address operator; // immutable uint256 expiration; // parameter dependent on a block.timestamp } /// @dev state fingerprint getter. /// @param tokenid id of a token state in question. /// @return current token state fingerprint. function getstatefingerprint(uint256 tokenid) override public view returns (bytes32) { state storage state = states[tokenid]; return keccak256( abi.encode( state.asset1, state.asset2, state.amount1, state.amount2, // state.fee don't need to be part of the fingerprint computation as it is immutable // state.operator don't need to be part of the fingerprint computation as it is immutable block.timestamp >= state.expiration ) ); } function supportsinterface(bytes4 interfaceid) public view virtual override returns (bool) { return super.supportsinterface(interfaceid) || interfaceid == type(erc5646).interfaceid; } } security considerations token state fingerprints from two different contracts may collide. because of that, they should be compared only in the context of one token contract. if the getstatefingerprint implementation does not include all parameters that could change the token state, a token owner would be able to change the token state without changing the token fingerprint. it could break the trustless assumptions of several protocols, which create, e.g., buy offers for tokens. the token owner would be able to change the state of the token before accepting an offer. copyright copyright and related rights waived via cc0. citation please cite this document as: naim ashhab (@ashhanai), "erc-5646: token state fingerprint," ethereum improvement proposals, no. 5646, september 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5646. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-2304: multichain address resolution for ens ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2304: multichain address resolution for ens authors nick johnson created 2019-09-09 discussion link https://discuss.ens.domains/t/new-standard-proposal-ens-multicoin-support/1148 requires eip-137 table of contents abstract motivation specification recommended accessor functions address encoding example implementation backwards compatibility tests copyright abstract this eip introduces new overloads for the the addr field for ens resolvers, which permit resolution of addresses for other blockchains via ens. motivation with the increasing uptake of ens by multi-coin wallets, wallet authors have requested the ability to resolve addresses for non-ethereum chains inside ens. this specification standardises a way to enter and retrieve these addresses in a cross-client fashion. specification a new accessor function for resolvers is specified: function addr(bytes32 node, uint cointype) external view returns(bytes memory); the eip165 interface id for this function is 0xf1cb7e06. when called on a resolver, this function must return the cryptocurrency address for the specified namehash and coin type. a zero-length string must be returned if the specified coin id does not exist on the specified node. cointype is the cryptocurrency coin type index from slip44. the return value is the cryptocurency address in its native binary format. detailed descriptions of the binary encodings for several popular chains are provided in the address encoding section below. a new event for resolvers is defined: event addresschanged(bytes32 indexed node, uint cointype, bytes newaddress); resolvers must emit this event on each change to the address for a name and coin type. recommended accessor functions the following function provides the recommended interface for changing the addresses stored for a node. resolvers should implement this interface for setting addresses unless their needs dictate a different interface. function setaddr(bytes32 node, uint cointype, bytes calldata addr); setaddr adds or replaces the address for the given node and coin type. the parameters for this function are as per those described in addr() above. this function emits an addresschanged event with the new address; see also the backwards compatibility section below for resolvers that also support addr(bytes32). address encoding in general, the native binary representation of the address should be used, without any checksum commonly used in the text representation. a table of encodings for common blockchains is provided, followed by a more detailed description of each format. in the table, ‘encodings’ lists the address encodings supported by that chain, along with any relevant parameters. details of those address encodings are described in the following sections. cryptocurrency coin type encoding bitcoin 0 p2pkh(0x00), p2sh(0x05), segwit(‘bc’) litecoin 2 p2pkh(0x30), p2sh(0x32), p2sh(0x05), segwit(‘ltc’) dogecoin 3 p2pkh(0x1e), p2sh(0x16) monacoin 22 p2pkh(0x32), p2sh(0x05) ethereum 60 checksummedhex ethereum classic 61 checksummedhex rootstock 137 checksummedhex(30) ripple 144 ripple bitcoin cash 145 p2pkh(0x00), p2sh(0x05), cashaddr binance 714 bech32(‘bnb’) p2pkh(version) pay to public key hash addresses are base58check encoded. after decoding, the first byte is a version byte. for example, the bitcoin address 1a1zp1ep5qgefi2dmptftl5slmv7divfna base58check decodes to the 21 bytes 0062e907b15cbf27d5425399ebf6f0fb50ebb88f18. p2pkh addresses have a version byte, followed by a 20 byte pubkey hash. their canonical encoding is their scriptpubkey encoding (specified here) is op_dup op_hash160 op_equalverify op_checksig. the above example address is thus encoded as the 25 bytes 76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac. p2sh(version) p2sh addresses are base58check encoded in the same manner as p2pkh addresses. p2sh addresses have a version, followed by a 20 byte script hash. their scriptpubkey encoding (specified here) is op_hash160 op_equal. a bitcoin address of 3ai1jz8pdjb2ksieuv8fsxsnvjcpopi8w6 decodes to the 21 bytes 0562e907b15cbf27d5425399ebf6f0fb50ebb88f18 and is encoded as the 23 bytes a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1887. segwit(hrp) segwit addresses are encoded with bech32. bech32 addresses consist of a human-readable part ‘bc’ for bitcoin mainnet and a machine readable part. for segwit addresses, this decodes to a ‘witness version’, between 0 and 15, and a ‘witness program’, as defined in bip141. the scriptpubkey encoding for a bech32 address, as defined in bip141, is op_n, where n is the witness version, followed by a push of the witness program. note this warning from bip173: implementations should take special care when converting the address to a scriptpubkey, where witness version n is stored as op_n. op_0 is encoded as 0x00, but op_1 through op_16 are encoded as 0x51 though 0x60 (81 to 96 in decimal). if a bech32 address is converted to an incorrect scriptpubkey the result will likely be either unspendable or insecure. for example, the bitcoin segwit address bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 decodes to a version of 0 and a witness script of 751e76e8199196d454941c45d1b3a323f1433bd6, and then encodes to a scriptpubkey of 0014751e76e8199196d454941c45d1b3a323f1433bd6. checksummedhex(chainid?) to translate a text format checksummed hex address into binary format, simply remove the ‘0x’ prefix and hex decode it. 0x314159265dd8dbb310642f98f50c066173c1259b is hex-decoded and stored as the 20 bytes 314159265dd8dbb310642f98f50c066173c1259b. a checksum format is specified by eip-55, and extended by rskip60, which specifies a means of including the chain id in the checksum. the checksum on a text format address must be checked. addresses with invalid checksums that are not all uppercase or all lowercase must be rejected with an error. implementations may choose whether to accept non-checksummed addresses, but the authors recommend at least providing a warning to users in this situation. when encoding an address from binary to text, an eip55/rskip60 checksum must be used so the correct encoding of the above address for ethereum is 0x314159265dd8dbb310642f98f50c066173c1259b. ripple ripple addresses are encoded using a version of base58check with an alternative alphabet, described here. two types of ripple addresses are supported, ‘r-addresses’, and ‘x-addresss’. r-addresses consist of a version byte followed by a 20 byte hash, while x-addresses consist of a version byte, a 20 byte hash, and a tag, specified here. both address types should be stored in ens by performing ripple’s version of base58check decoding and storing them directly (including version byte). for example, the ripple address rf1bigexwwqoi8z2uefytexswujyfv2jpn decodes to and is stored as 004b4e9c06f24296074f7bc48f92a97916c6dc5ea9, while the address x7qvls7gsnnokvzznwut2e8st17qpy64ppe7zrilnujszeg decodes to and is stored as 05444b4e9c06f24296074f7bc48f92a97916c6dc5ea9000000000000000000. cashaddr bitcoin cash defines a new address format called ‘cashaddr’, specified here. this uses a variant of bech32 encoding to encode and decode (non-segwit) bitcoin cash addresses, using a prefix of ‘bitcoincash:’. a cashaddr should be decoded using this bech32 variant, then converted and stored based on its type (p2pkh or p2sh) as described in the relevant sections above. bech32 bech32 addresses consist of a human-readable part for example, ‘bnb’ for binance and a machine readable part. the encoded data is simply the address, which can be converted to binary and stored directly. for example, the bnb address bnb1grpf0955h0ykzq3ar5nmum7y6gdfl6lxfn46h2 decodes to the binary representation 40c2979694bbc961023d1d27be6fc4d21a9febe6, which is stored directly in ens. example an example implementation of a resolver that supports this eip is provided here: pragma solidity ^0.5.8; contract addrresolver is resolverbase { bytes4 constant private addr_interface_id = 0x3b3b57de; bytes4 constant private address_interface_id = 0xf1cb7e06; uint constant private coin_type_eth = 60; event addrchanged(bytes32 indexed node, address a); event addresschanged(bytes32 indexed node, uint cointype, bytes newaddress); mapping(bytes32=>mapping(uint=>bytes)) _addresses; /** * sets the address associated with an ens node. * may only be called by the owner of that node in the ens registry. * @param node the node to update. * @param a the address to set. */ function setaddr(bytes32 node, address a) external authorised(node) { setaddr(node, coin_type_eth, addresstobytes(a)); } /** * returns the address associated with an ens node. * @param node the ens node to query. * @return the associated address. */ function addr(bytes32 node) public view returns (address) { bytes memory a = addr(node, coin_type_eth); if(a.length == 0) { return address(0); } return bytestoaddress(a); } function setaddr(bytes32 node, uint cointype, bytes memory a) public authorised(node) { emit addresschanged(node, cointype, a); if(cointype == coin_type_eth) { emit addrchanged(node, bytestoaddress(a)); } _addresses[node][cointype] = a; } function addr(bytes32 node, uint cointype) public view returns(bytes memory) { return _addresses[node][cointype]; } function supportsinterface(bytes4 interfaceid) public pure returns(bool) { return interfaceid == addr_interface_id || interfaceid == address_interface_id || super.supportsinterface(interfaceid); } } implementation an implementation of this interface is provided in the ensdomains/resolvers repository. backwards compatibility if the resolver supports the addr(bytes32) interface defined in eip137, the resolver must treat this as a special case of this new specification in the following ways: the value returned by addr(node) from eip137 should always match the value returned by addr(node, 60) (60 is the coin type id for ethereum). anything that causes the addrchanged event from eip137 to be emitted must also emit an addresschanged event from this eip, with the cointype specified as 60, and vice-versa. tests the table below specifies test vectors for valid address encodings for each cryptocurrency described above. cryptocurrency coin type text onchain (hex) bitcoin 0 1a1zp1ep5qgefi2dmptftl5slmv7divfna 76a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1888ac 3ai1jz8pdjb2ksieuv8fsxsnvjcpopi8w6 a91462e907b15cbf27d5425399ebf6f0fb50ebb88f1887 bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4 0014751e76e8199196d454941c45d1b3a323f1433bd6 litecoin 2 lamt348pwrnrqeewarpwqpbuanpxdzgeuz 76a914a5f4d12ce3685781b227c1f39548ddef429e978388ac mqmcjhpwhyveqarczr3sbgypzxxrtnh441 a914b48297bff5dadecc5f36145cec6a5f20d57c8f9b87 ltc1qdp7p2rpx4a2f80h7a4crvppczgg4egmv5c78w8 0014687c150c26af5493befeed7036043812115ca36c dogecoin 3 dbxu2kgc3xtvcuwfcxfe3r9heygmuaacyd 76a9144620b70031f0e9437e374a2100934fba4911046088ac af8ekvsf6eisbrspjjnfzk6d1em6pnpq3g a914f8f5d99a9fc21aa676e74d15e7b8134557615bda87 monacoin 22 mhxgs2xmxjej4if2prrbwycdwzpwfdwadt 76a9146e5bb7226a337fe8307b4192ae5c3fab9fa9edf588ac ethereum 60 0x314159265dd8dbb310642f98f50c066173c1259b 314159265dd8dbb310642f98f50c066173c1259b ethereum classic 61 0x314159265dd8dbb310642f98f50c066173c1259b 314159265dd8dbb310642f98f50c066173c1259b rootstock 137 0x5aaeb6053f3e94c9b9a09f33669435e7ef1beaed 5aaeb6053f3e94c9b9a09f33669435e7ef1beaed ripple 144 rf1bigexwwqoi8z2uefytexswujyfv2jpn 004b4e9c06f24296074f7bc48f92a97916c6dc5ea9 x7qvls7gsnnokvzznwut2e8st17qpy64ppe7zrilnujszeg 05444b4e9c06f24296074f7bc48f92a97916c6dc5ea9000000000000000000 bitcoin cash 145 1bpei6dfdaufd7gtittlsdbeyjvcoavggu 76a91476a04053bda0a88bda5177b86a15c3b29f55987388ac bitcoincash:qpm2qsznhks23z7629mms6s4cwef74vcwvy22gdx6a 76a91476a04053bda0a88bda5177b86a15c3b29f55987388ac 3cwfddi6m4ndigykqzyvsfyagqdlpvmtzc a91476a04053bda0a88bda5177b86a15c3b29f55987387 bitcoincash:ppm2qsznhks23z7629mms6s4cwef74vcwvn0h829pq a91476a04053bda0a88bda5177b86a15c3b29f55987387 binance 714 bnb1grpf0955h0ykzq3ar5nmum7y6gdfl6lxfn46h2 40c2979694bbc961023d1d27be6fc4d21a9febe6 copyright copyright and related rights waived via cc0. citation please cite this document as: nick johnson , "erc-2304: multichain address resolution for ens [draft]," ethereum improvement proposals, no. 2304, september 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2304. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2228: canonicalize the name of network id 1 and chain id 1 ethereum improvement proposals allcorenetworkinginterfaceercmetainformational informational eip-2228: canonicalize the name of network id 1 and chain id 1 authors william entriken (@fulldecent) created 2019-08-04 table of contents simple summary abstract motivation specification trademark note rationale backwards compatibility test cases examples referencing the name of the network ✅ examples referencing the network in a descriptive way ✅ examples of other correct word usage ✅ examples of poor word choice (avoid this) ❌ copyright simple summary the ethereum network with network id 1 and chain id 1 is named ethereum mainnet. abstract the name for the ethereum network with network id 1 and chain id 1 shall be ethereum mainnet or just mainnet. this is a proper noun. this standard specifies the name for this network and provides reference examples in an effort to standardize the word choice and provide a common language for use to refer to this network. motivation the ethereum network with network id 1 and chain id 1 is referenced using several conflicting names across eips, client implementations, and information published on the internet at large. in several locations, even documents written by the same author use inconsistent names to refer to the ethereum network with network id 1 and chain id 1. names in use at the time of this writing include: “main net” “mainnet” “main net” “mainnet” specification the network name for network id 1 and chain id 1 shall be ethereum mainnet, or just mainnet if the context is known to be discussing ethereum networks. this is a proper noun. several examples are given below which differentiate between usage of the name of the network versus a descriptive reference to the network. any name or word styling (i.e. capitalization of the letters) of the network which is inconsistent with the test cases cited below shall not be used. trademark note “ethereum” is trademarked by the ethereum foundation. for more information on your obligations when mentioning “ethereum”, and possibly “ethereum mainnet”, see: uspto registration number 5110579 by ethereum foundation the note “you must not use [this mark] without the prior written permission of the foundation” on the ethereum foundation website, terms of use page rationale choosing common word use promotes interoperability of implementations and increases customer awareness. also, it adds a sense of professionalism when customers see the same word and word styling (i.e. capitalization of letters) across different implementations. anybody that has travelled to certain countries and seen an “iphone [sic]” repair store should immediately recognize that this is off-brand and unofficial. likewise, the astute customer of ethereum should recognize if they see the network referred to using inconsistent names in different software, so let’s avoid this. backwards compatibility metamask previously used “main ethereum network” in the account network chooser. metamask has been updated consistent with this eip. references to mainnet that are inconsistent with this specification are made in: eip-2, eip-779, eip-150, eip-155, eip-190, eip-225, eip-1013, eip-2028, and eip-2387. for consistency, we recommend the editor will update eips to consistently use the name as specified in this eip. test cases examples referencing the name of the network ✅ the contract was deployed to ethereum mainnet. ethereum runs many applications, this dapp was deployed to mainnet. no specification is made on whether dapp, dapp, dapp, etc. is preferred. switch to mainnet this example shows a user interface which is in uppercase. to be semantically correct, this could be written in html as switch to mainnet. switch to mainnet this example shows a user interface which is in lowercase. to be semantically correct, this could be written in html as switch to mainnet. examples referencing the network in a descriptive way ✅ mainnet has ### times the number of transactions as the test networks. examples of other correct word usage ✅ the main network on ethereum is mainnet this shows that “main” is used as a descriptive word, but mainnet is the specific network which is having network id 1 and chain id 1. examples of poor word choice (avoid this) ❌ deploy your contract to the ethereum main network. this is referring to a “main” network which is context-dependent. if you were reading this text on a page about ethereum classic, they would be referring to network id 2 and chain id 62. therefore this word usage is less crisp. do not use wording like this. connect to mainnet. these words literally mean nothing. the lowercase, not-proper-noun word “mainnet” is not a plain english word and it should not be in any dictionary. do not use wording like this. copyright copyright and related rights waived via cc0. citation please cite this document as: william entriken (@fulldecent), "eip-2228: canonicalize the name of network id 1 and chain id 1," ethereum improvement proposals, no. 2228, august 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2228. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-101: serenity currency and crypto abstraction ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-101: serenity currency and crypto abstraction authors vitalik buterin (@vbuterin) created 2015-11-15 table of contents specification rationale implementation specification accounts now have only two fields in their rlp encoding: code and storage. ether is no longer stored in account objects directly; instead, at address 0, we premine a contract which contains all ether holdings. the eth.getbalance command in web3 is remapped appropriately. msg.value no longer exists as an opcode. a transaction now only has four fields: to, startgas, data and code. aside from an rlp validity check, and checking that the to field is twenty bytes long, the startgas is an integer, and code is either empty or hashes to the to address, there are no other validity constraints; anything goes. however, the block gas limit remains, so miners are disincentivized from including junk. gas is charged for bytes in code at the same rate as data. when a transaction is sent, if the receiving account does not yet exist, the account is created, and its code is set to the code provided in the transaction; otherwise the code is ignored. a tx.gas opcode is added alongside the existing msg.gas at index 0x5c; this new opcode allows the transaction to access the original amount of gas allotted for the transaction note that ecrecover, sequence number/nonce incrementing and ether are now nowhere in the bottom-level spec (note: ether is going to continue to have a privileged role in casper pos). to replicate existing functionality under the new model, we do the following. simple user accounts can have the following default standardized code: # we assume that data takes the following schema: # bytes 0-31: v (ecdsa sig) # bytes 32-63: r (ecdsa sig) # bytes 64-95: s (ecdsa sig) # bytes 96-127: sequence number (formerly called "nonce") # bytes 128-159: gasprice # bytes 172-191: to # bytes 192+: data # get the hash for transaction signing ~mstore(0, msg.gas) ~calldatacopy(32, 96, ~calldatasize() 96) h = sha3(96, ~calldatasize() 96) # call ecrecover contract to get the sender ~call(5000, 3, [h, ~calldataload(0), ~calldataload(32), ~calldataload(64)], 128, ref(addr), 32) # check sender correctness assert addr == 0x82a978b3f5962a5b0957d9ee9eef472ee55b42f1 # check sequence number correctness assert ~calldataload(96) == self.storage[-1] # increment sequence number self.storage[-1] += 1 # make the sub-call and discard output ~call(msg.gas 50000, ~calldataload(160), 192, ~calldatasize() 192, 0, 0) # pay for gas ~call(40000, 0, [send, block.coinbase, ~calldataload(128) * (tx.gas msg.gas + 50000)], 96, 0, 0) this essentially implements signature and nonce checking, and if both checks pass then it uses all remaining gas minus 50000 to send the actual desired call, and then finally pays for gas. miners can follow the following algorithm upon receiving transactions: run the code for a maximum of 50000 gas, stopping if they see an operation or call that threatens to go over this limit upon seeing that operation, make sure that it leaves at last 50000 gas to spare (either by checking that the static gas consumption is small enough or by checking that it is a call with msg.gas 50000 as its gas limit parameter) pattern-match to make sure that gas payment code at the end is exactly the same as in the code above. this process ensures that miners waste at most 50000 gas before knowing whether or not it will be worth their while to include the transaction, and is also highly general so users can experiment with new cryptography (eg. ed25519, lamport), ring signatures, quasi-native multisig, etc. theoretically, one can even create an account for which the valid signature type is a valid merkle branch of a receipt, creating a quasi-native alarm clock. if someone wants to send a transaction with nonzero value, instead of the current msg.sender approach, we compile into a three step process: in the outer scope just before calling, call the ether contract to create a cheque for the desired amount in the inner scope, if a contract uses the msg.value opcode anywhere in the function that is being called, then we have the contract cash out the cheque at the start of the function call and store the amount cashed out in a standardized address in memory in the outer scope just after calling, send a message to the ether contract to disable the cheque if it has not yet been cashed rationale this allows for a large increase in generality, particularly in a few areas: cryptographic algorithms used to secure accounts (we could reasonably say that ethereum is quantum-safe, as one is perfectly free to secure one’s account with lamport signatures). the nonce-incrementing approach is now also open to revision on the part of account holders, allowing for experimentation in k-parallelizable nonce techniques, utxo schemes, etc. moving ether up a level of abstraction, with the particular benefit of allowing ether and sub-tokens to be treated similarly by contracts reducing the level of indirection required for custom-policy accounts such as multisigs it also substantially simplifies and purifies the underlying ethereum protocol, reducing the minimal consensus implementation complexity. implementation coming soon. citation please cite this document as: vitalik buterin (@vbuterin), "eip-101: serenity currency and crypto abstraction [draft]," ethereum improvement proposals, no. 101, november 2015. [online serial]. available: https://eips.ethereum.org/eips/eip-101. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. programming society with asm: gavin wood at assembly 2014 | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search programming society with asm: gavin wood at assembly 2014 posted by stephan tual on august 6, 2014 research & development previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-4987: held token interface ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-4987: held token interface interface to query ownership and balance of held tokens authors devin conley (@devinaconley) created 2021-09-21 discussion link https://ethereum-magicians.org/t/eip-4987-held-token-standard-nfts-defi/7117 requires eip-20, eip-165, eip-721, eip-1155 table of contents abstract motivation specification rationale backwards compatibility reference implementation security considerations copyright abstract the proposed standard defines a lightweight interface to expose functional ownership and balances of held tokens. a held token is a token owned by a contract. this standard may be implemented by smart contracts which hold eip-20, eip-721, or eip-1155 tokens and is intended to be consumed by both on-chain and off-chain systems that rely on ownership and balance verification. motivation as different areas of crypto (defi, nfts, etc.) converge and composability improves, there will more commonly be a distinction between the actual owner (likely a contract) and the functional owner (likely a user) of a token. currently, this results in a conflict between mechanisms that require token deposits and systems that rely on those tokens for ownership or balance verification. this proposal aims to address that conflict by providing a standard interface for token holders to expose ownership and balance information. this will allow users to participate in these defi mechanisms without giving up existing token utility. overall, this would greatly increase interoperability across systems, benefiting both users and protocol developers. example implementers of this erc standard include staking or farming contracts lending pools time lock or vesting vaults fractionalized nft contracts smart contract wallets example consumers of this erc standard include governance systems gaming pfp verification art galleries or showcases token based membership programs specification smart contracts implementing the erc20 held token standard must implement all of the functions in the ierc20holder interface. smart contracts implementing the erc20 held token standard must also implement erc165 and return true when the interface id 0x74c89d54 is passed. /** * @notice the erc20 holder standard provides a common interface to query * token balance information */ interface ierc20holder is ierc165 { /** * @notice emitted when the token is transferred to the contract * @param owner functional token owner * @param tokenaddress held token address * @param tokenamount held token amount */ event hold( address indexed owner, address indexed tokenaddress, uint256 tokenamount ); /** * @notice emitted when the token is released back to the user * @param owner functional token owner * @param tokenaddress held token address * @param tokenamount held token amount */ event release( address indexed owner, address indexed tokenaddress, uint256 tokenamount ); /** * @notice get the held balance of the token owner * @dev should throw for invalid queries and return zero for no balance * @param tokenaddress held token address * @param owner functional token owner * @return held token balance */ function heldbalanceof(address tokenaddress, address owner) external view returns (uint256); } smart contracts implementing the erc721 held token standard must implement all of the functions in the ierc721holder interface. smart contracts implementing the erc721 held token standard must also implement erc165 and return true when the interface id 0x16b900ff is passed. /** * @notice the erc721 holder standard provides a common interface to query * token ownership and balance information */ interface ierc721holder is ierc165 { /** * @notice emitted when the token is transferred to the contract * @param owner functional token owner * @param tokenaddress held token address * @param tokenid held token id */ event hold( address indexed owner, address indexed tokenaddress, uint256 indexed tokenid ); /** * @notice emitted when the token is released back to the user * @param owner functional token owner * @param tokenaddress held token address * @param tokenid held token id */ event release( address indexed owner, address indexed tokenaddress, uint256 indexed tokenid ); /** * @notice get the functional owner of a held token * @dev should throw for invalid queries and return zero for a token id that is not held * @param tokenaddress held token address * @param tokenid held token id * @return functional token owner */ function heldownerof(address tokenaddress, uint256 tokenid) external view returns (address); /** * @notice get the held balance of the token owner * @dev should throw for invalid queries and return zero for no balance * @param tokenaddress held token address * @param owner functional token owner * @return held token balance */ function heldbalanceof(address tokenaddress, address owner) external view returns (uint256); } smart contracts implementing the erc1155 held token standard must implement all of the functions in the ierc1155holder interface. smart contracts implementing the erc1155 held token standard must also implement erc165 and return true when the interface id 0xced24c37 is passed. /** * @notice the erc1155 holder standard provides a common interface to query * token balance information */ interface ierc1155holder is ierc165 { /** * @notice emitted when the token is transferred to the contract * @param owner functional token owner * @param tokenaddress held token address * @param tokenid held token id * @param tokenamount held token amount */ event hold( address indexed owner, address indexed tokenaddress, uint256 indexed tokenid, uint256 tokenamount ); /** * @notice emitted when the token is released back to the user * @param owner functional token owner * @param tokenaddress held token address * @param tokenid held token id * @param tokenamount held token amount */ event release( address indexed owner, address indexed tokenaddress, uint256 indexed tokenid, uint256 tokenamount ); /** * @notice get the held balance of the token owner * @dev should throw for invalid queries and return zero for no balance * @param tokenaddress held token address * @param owner functional token owner * @param tokenid held token id * @return held token balance */ function heldbalanceof( address tokenaddress, address owner, uint256 tokenid ) external view returns (uint256); } rationale this interface is designed to be extremely lightweight and compatible with any existing token contract. any token holder contract likely already stores all relevant information, so this standard is purely adding a common interface to expose that data. the token address parameter is included to support contracts that can hold multiple token contracts simultaneously. while some contracts may only hold a single token address, this is more general to either scenario. separate interfaces are proposed for each token type (eip-20, eip-721, eip-1155) because any contract logic to support holding these different tokens is likely independent. in the scenario where a single contract does hold multiple token types, it can simply implement each appropriate held token interface. backwards compatibility importantly, the proposed specification is fully compatible with all existing eip-20, eip-721, and eip-1155 token contracts. token holder contracts will need to be updated to implement this lightweight interface. consumer of this standard will need to be updated to respect this interface in any relevant ownership logic. reference implementation a full example implementation including interfaces, a vault token holder, and a consumer, can be found at assets/eip-4987/. notably, consumers of the ierc721holder interface can do a chained lookup for the owner of any specific token id using the following logic. /** * @notice get the functional owner of a token * @param tokenid token id of interest */ function getowner(uint256 tokenid) external view returns (address) { // get raw owner address owner = token.ownerof(tokenid); // if owner is not contract, return if (!owner.iscontract()) { return owner; } // check for token holder interface support try ierc165(owner).supportsinterface(0x16b900ff) returns (bool ret) { if (!ret) return owner; } catch { return owner; } // check for held owner try ierc721holder(owner).heldownerof(address(token), tokenid) returns (address user) { if (user != address(0)) return user; } catch {} return owner; } security considerations consumers of this standard should be cautious when using ownership information from unknown contracts. a bad actor could implement the interface, but report invalid or malicious information with the goal of manipulating a governance system, game, membership program, etc. consumers should also verify the overall token balance and ownership of the holder contract as a sanity check. copyright copyright and related rights waived via cc0. citation please cite this document as: devin conley (@devinaconley), "erc-4987: held token interface [draft]," ethereum improvement proposals, no. 4987, september 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4987. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6981: reserved ownership accounts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-6981: reserved ownership accounts a registry for generating future-deployed smart contract accounts owned by users on external services authors paul sullivan (@sullivph) , wilkins chung (@wwchung) , kartik patel (@slokh) created 2023-04-25 discussion link https://ethereum-magicians.org/t/erc-6981-reserved-ownership-accounts/14118 requires eip-1167, eip-1271, eip-6492 table of contents abstract motivation specification overview account registry account instance rationale service-owned registry instances account registry and account implementation coupling separate createaccount and claimaccount operations reference implementation account registry factory account registry example account implementation security considerations front-running copyright abstract the following specifies a system for services to link their users to a claimable ethereum address. services can provide a signed message and unique salt to their users which can be used to deploy a smart contract wallet to the deterministic address through a registry contract using the create2 opcode. motivation it is common for web services to allow their users to hold on-chain assets via custodial wallets. these wallets are typically eoas, deployed smart contract wallets or omnibus contracts, with private keys or asset ownership information stored on a traditional database. this proposal outlines a solution that avoids the security concerns associated with historical approaches, and rids the need and implications of services controlling user assets users on external services that choose to leverage the following specification can be given an ethereum address to receive assets without the need to do any on-chain transaction. these users can choose to attain control of said addresses at a future point in time. thus, on-chain assets can be sent to and owned by a user beforehand, therefore enabling the formation of an on-chain identity without requiring the user to interact with the underlying blockchain. 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. overview the system for creating reserved ownership accounts consists of: an account registry which provides deterministic addresses based on the service users’ identifying salts, and implements a signature verified function that enables claiming of account instances by the service’s end users. account instances created through the account registry by end users which allow access to the assets received at the deterministic address prior to account instance deployment. external services wishing to provide their users with reserved ownership accounts must maintain a relationship between a user’s identifying credentials and a salt. the external service shall refer to an account registry instance to retrieve the deterministic account address for a given salt. users of a given service must be able to create an account instance by validating their identifying credentials via the external service, which should give the user a signed message for their salt. signatures should be generated by the external service using an signing address known to the account registry instance. users shall pass this message and signature to the service’s account registry instance in a call to claimaccount to deploy and claim an account instance at the deterministic address. account registry the account registry must implement the following interface: interface iaccountregistry { /** * @dev registry instances emit the accountcreated event upon successful account creation */ event accountcreated(address account, address accountimplementation, uint256 salt); /** * @dev registry instances emit the accountclaimed event upon successful claim of account by owner */ event accountclaimed(address account, address owner); /** * @dev creates a smart contract account. * * if account has already been created, returns the account address without calling create2. * * @param salt the identifying salt for which the user wishes to deploy an account instance * * emits accountcreated event * @return the address for which the account instance was created */ function createaccount(uint256 salt) external returns (address); /** * @dev allows an owner to claim a smart contract account created by this registry. * * if the account has not already been created, the account will be created first using `createaccount` * * @param owner the initial owner of the new account instance * @param salt the identifying salt for which the user wishes to deploy an account instance * @param expiration if expiration > 0, represents expiration time for the signature. otherwise * signature does not expire. * @param message the keccak256 message which validates the owner, salt, expiration * @param signature the signature which validates the owner, salt, expiration * * emits accountclaimed event * @return the address of the claimed account instance */ function claimaccount( address owner, uint256 salt, uint256 expiration, bytes32 message, bytes calldata signature ) external returns (address); /** * @dev returns the computed address of a smart contract account for a given identifying salt * * @return the computed address of the account */ function account(uint256 salt) external view returns (address); /** * @dev fallback signature verification for unclaimed accounts */ function isvalidsignature(bytes32 hash, bytes memory signature) external view returns (bytes4); } createaccount createaccount is used to deploy the account instance for a given salt. this function must deploy a new account instance as a erc-1167 proxy pointing to the account implementation. this function should set the initial owner of the account instance to the account registry instance. the account implementation address must be immutable, as it is used to compute the deterministic address for the account instance. upon successful deployment of the account instance, the registry should emit an accountcreated event. claimaccount claimaccount is used to claim ownership of the account instance for a given salt. this function must create a new account instance if one does not already exist for the given salt. this function should verify that the msg.sender has permission to claim ownership over the account instance for the identifying salt and initial owner. verification should be done by validating the message and signature against the owner, salt and expiration using ecdsa for eoa signers, or erc-1271 for smart contract signers. this function should verify that the block.timestamp < expiration or that expiration == 0. upon successful signature verification on calls to claimaccount, the registry must completely relinquish control over the account instance, and assign ownership to the initial owner by calling setowner on the account instance. upon successful claim of the account instance, the registry should emit an accountclaimed event. isvalidsignature isvalidsignature is a fallback signature verification function used by unclaimed accounts. valid signatures shall be generated by the registry signer by signing a composite hash of the original message hash, and the account instance address (e.g. bytes32 compositehash = keccak256(abi.encodepacked(originalhash, accountaddress))). the function must reconstruct the composite hash, where originalhash is the hash passed to the function, and accountaddress is msg.sender (the unclaimed account instance). the function must verify the signature against the composite hash and registry signer. account instance the account instance must implement the following interface: interface iaccount is ierc1271 { /** * @dev sets the owner of the account instance. * * only callable by the current owner of the instance, or by the registry if the account * instance has not yet been claimed. * * @param owner the new owner of the account instance */ function setowner(address owner) external; } all account instances must be created using an account registry instance. account instances should provide access to assets previously sent to the address at which the account instance is deployed to. setowner should update the owner and should be callable by the current owner of the account instance. if an account instance is deployed, but not claimed, the owner of the account instance must be initialized to the account registry instance. an account instance shall determine if it has been claimed by checking if the owner is the account registry instance. account instance signatures account instances must support erc-1271 by implementing an isvalidsignature function. when the owner of an account instance wants to sign a message (e.g. to log in to a dapp), the signature must be generated in one of the following ways, depending the state of the account instance: if the account instance is deployed and claimed, the owner should generate the signature, and isvalidsignature should verify that the message hash and signature are valid for the current owner of the account instance. if the account instance is deployed, but unclaimed, the registry signer should generate the signature using a composite hash of the original message and address of the account instance described above, and isvalidsignature should forward the message hash and signature to the account registry instance’s isvalidsignature function. if the account instance is not deployed, the registry signer should generate a signature on the composite hash as done in situation 2, and wrap the signature according to erc-6492 (e.g. concat(abi.encode((registryaddress, createaccountcalldata, compositehashsignature), (address, bytes, bytes)), magicbytes)). signature validation for account instances should be done according to erc-6492. rationale service-owned registry instances while it might seem more user-friendly to implement and deploy a universal registry for reserved ownership accounts, we believe that it is important for external service providers to have the option to own and control their own account registry. this provides the flexibility of implementing their own permission controls and account deployment authorization frameworks. we are providing a reference registry factory which can deploy account registries for an external service, which comes with: immutable account instance implementation validation for the claimaccount method via ecdsa for eoa signers, or erc-1271 validation for smart contract signers ability for the account registry deployer to change the signing addressed used for claimaccount validation account registry and account implementation coupling since account instances are deployed as erc-1167 proxies, the account implementation address affects the addresses of accounts deployed from a given account registry. requiring that registry instances be linked to a single, immutable account implementation ensures consistency between a user’s salt and linked address on a given account registry instance. this also allows services to gain the the trust of users by deploying their registries with a reference to a trusted account implementation address. furthermore, account implementations can be designed as upgradeable, so users are not necessarily bound to the implementation specified by the account registry instance used to create their account. separate createaccount and claimaccount operations operations to create and claim account instances are intentionally separate. this allows services to provide users with valid erc-6492 signatures before their account instance has been deployed. reference implementation the following is an example of an account registry factory which can be used by external service providers to deploy their own account registry instance. account registry factory // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.13; /// @author: manifold.xyz import {create2} from "openzeppelin/utils/create2.sol"; import {address} from "../../lib/address.sol"; import {erc1167proxybytecode} from "../../lib/erc1167proxybytecode.sol"; import {iaccountregistryfactory} from "./iaccountregistryfactory.sol"; contract accountregistryfactory is iaccountregistryfactory { using address for address; error initializationfailed(); address private immutable registryimplementation = 0x076b08ede2b28fab0c1886f029cd6d02c8ff0e94; function createregistry( uint96 index, address accountimplementation, bytes calldata accountinitdata ) external returns (address) { bytes32 salt = _getsalt(msg.sender, index); bytes memory code = erc1167proxybytecode.createcode(registryimplementation); address _registry = create2.computeaddress(salt, keccak256(code)); if (_registry.isdeployed()) return _registry; _registry = create2.deploy(0, salt, code); (bool success, ) = _registry.call( abi.encodewithsignature( "initialize(address,address,bytes)", msg.sender, accountimplementation, accountinitdata ) ); if (!success) revert initializationfailed(); emit accountregistrycreated(_registry, accountimplementation, index); return _registry; } function registry(address deployer, uint96 index) external view override returns (address) { bytes32 salt = _getsalt(deployer, index); bytes memory code = erc1167proxybytecode.createcode(registryimplementation); return create2.computeaddress(salt, keccak256(code)); } function _getsalt(address deployer, uint96 index) private pure returns (bytes32) { return bytes32(abi.encodepacked(deployer, index)); } } account registry // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.13; /// @author: manifold.xyz import {create2} from "openzeppelin/utils/create2.sol"; import {ecdsa} from "openzeppelin/utils/cryptography/ecdsa.sol"; import {ownable} from "openzeppelin/access/ownable.sol"; import {initializable} from "openzeppelin/proxy/utils/initializable.sol"; import {ierc1271} from "openzeppelin/interfaces/ierc1271.sol"; import {signaturechecker} from "openzeppelin/utils/cryptography/signaturechecker.sol"; import {address} from "../../lib/address.sol"; import {iaccountregistry} from "../../interfaces/iaccountregistry.sol"; import {erc1167proxybytecode} from "../../lib/erc1167proxybytecode.sol"; contract accountregistryimplementation is ownable, initializable, iaccountregistry { using address for address; using ecdsa for bytes32; struct signer { address account; bool iscontract; } error initializationfailed(); error claimfailed(); error unauthorized(); address public accountimplementation; bytes public accountinitdata; signer public signer; constructor() { _disableinitializers(); } function initialize( address owner, address accountimplementation_, bytes calldata accountinitdata_ ) external initializer { _transferownership(owner); accountimplementation = accountimplementation_; accountinitdata = accountinitdata_; } /** * @dev see {iaccountregistry-createaccount} */ function createaccount(uint256 salt) external override returns (address) { bytes memory code = erc1167proxybytecode.createcode(accountimplementation); address _account = create2.computeaddress(bytes32(salt), keccak256(code)); if (_account.isdeployed()) return _account; _account = create2.deploy(0, bytes32(salt), code); (bool success, ) = _account.call(accountinitdata); if (!success) revert initializationfailed(); emit accountcreated(_account, accountimplementation, salt); return _account; } /** * @dev see {iaccountregistry-claimaccount} */ function claimaccount( address owner, uint256 salt, uint256 expiration, bytes32 message, bytes calldata signature ) external override returns (address) { _verify(owner, salt, expiration, message, signature); address _account = this.createaccount(salt); (bool success, ) = _account.call( abi.encodewithsignature("transferownership(address)", owner) ); if (!success) revert claimfailed(); emit accountclaimed(_account, owner); return _account; } /** * @dev see {iaccountregistry-account} */ function account(uint256 salt) external view override returns (address) { bytes memory code = erc1167proxybytecode.createcode(accountimplementation); return create2.computeaddress(bytes32(salt), keccak256(code)); } /** * @dev see {iaccountregistry-isvalidsignature} */ function isvalidsignature(bytes32 hash, bytes memory signature) external view returns (bytes4) { bytes32 expectedhash = keccak256(abi.encodepacked(hash, msg.sender)); bool isvalid = signaturechecker.isvalidsignaturenow( signer.account, expectedhash, signature ); if (isvalid) { return ierc1271.isvalidsignature.selector; } return ""; } function updatesigner(address newsigner) external onlyowner { uint32 signersize; assembly { signersize := extcodesize(newsigner) } signer.account = newsigner; signer.iscontract = signersize > 0; } function _verify( address owner, uint256 salt, uint256 expiration, bytes32 message, bytes calldata signature ) internal view { address signatureaccount; if (signer.iscontract) { if (!signaturechecker.isvalidsignaturenow(signer.account, message, signature)) revert unauthorized(); } else { signatureaccount = message.recover(signature); } bytes32 expectedmessage = keccak256( abi.encodepacked("\x19ethereum signed message:\n84", owner, salt, expiration) ); if ( message != expectedmessage || (!signer.iscontract && signatureaccount != signer.account) || (expiration != 0 && expiration < block.timestamp) ) revert unauthorized(); } } example account implementation // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.13; /// @author: manifold.xyz import {ierc1271} from "openzeppelin/interfaces/ierc1271.sol"; import {signaturechecker} from "openzeppelin/utils/cryptography/signaturechecker.sol"; import {ierc165} from "openzeppelin/utils/introspection/ierc165.sol"; import {erc165checker} from "openzeppelin/utils/introspection/erc165checker.sol"; import {ierc721} from "openzeppelin/token/erc721/ierc721.sol"; import {ierc721receiver} from "openzeppelin/token/erc721/ierc721receiver.sol"; import {ierc1155receiver} from "openzeppelin/token/erc1155/ierc1155receiver.sol"; import {initializable} from "openzeppelin/proxy/utils/initializable.sol"; import {ownable} from "openzeppelin/access/ownable.sol"; import {ierc1967account} from "./ierc1967account.sol"; import {iaccount} from "../../interfaces/iaccount.sol"; /** * @title erc1967accountimplementation * @notice a lightweight, upgradeable smart contract wallet implementation */ contract erc1967accountimplementation is iaccount, ierc165, ierc721receiver, ierc1155receiver, ierc1967account, initializable, ownable { address public registry; constructor() { _disableinitializers(); } function initialize() external initializer { registry = msg.sender; _transferownership(registry); } function supportsinterface(bytes4 interfaceid) external pure returns (bool) { return (interfaceid == type(iaccount).interfaceid || interfaceid == type(ierc1967account).interfaceid || interfaceid == type(ierc1155receiver).interfaceid || interfaceid == type(ierc721receiver).interfaceid || interfaceid == type(ierc165).interfaceid); } function onerc721received( address, address, uint256, bytes memory ) public pure returns (bytes4) { return this.onerc721received.selector; } function onerc1155received( address, address, uint256, uint256, bytes memory ) public pure returns (bytes4) { return this.onerc1155received.selector; } function onerc1155batchreceived( address, address, uint256[] memory, uint256[] memory, bytes memory ) public pure returns (bytes4) { return this.onerc1155batchreceived.selector; } /** * @dev {see ierc1967account-executecall} */ function executecall( address _target, uint256 _value, bytes calldata _data ) external payable override onlyowner returns (bytes memory _result) { bool success; // solhint-disable-next-line avoid-low-level-calls (success, _result) = _target.call{value: _value}(_data); require(success, string(_result)); emit transactionexecuted(_target, _value, _data); return _result; } /** * @dev {see iaccount-setowner} */ function setowner(address _owner) external override onlyowner { _transferownership(_owner); } receive() external payable {} function isvalidsignature(bytes32 hash, bytes memory signature) external view returns (bytes4) { if (owner() == registry) { return ierc1271(registry).isvalidsignature(hash, signature); } bool isvalid = signaturechecker.isvalidsignaturenow(owner(), hash, signature); if (isvalid) { return ierc1271.isvalidsignature.selector; } return ""; } } security considerations front-running deployment of reserved ownership accounts through an account registry instance through calls to createaccount could be front-run by a malicious actor. however, if the malicious actor attempted to alter the owner parameter in the calldata, the account registry instance would find the signature to be invalid, and revert the transaction. thus, any successful front-running transaction would deploy an identical account instance to the original transaction, and the original owner would still gain control over the address. copyright copyright and related rights waived via cc0. citation please cite this document as: paul sullivan (@sullivph) , wilkins chung (@wwchung) , kartik patel (@slokh) , "erc-6981: reserved ownership accounts [draft]," ethereum improvement proposals, no. 6981, april 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6981. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-998: composable non-fungible token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-998: composable non-fungible token extends a erc-721 to own other erc-721 and erc-20 tokens. authors matt lockyer , nick mudge , jordan schalm , sebastian echeverry , zainan victor zhou (@xinbenlv) created 2018-07-07 discussion link https://ethereum-magicians.org/t/erc-998-composable-non-fungible-tokens-cnfts/387 requires eip-20, eip-165, eip-721 table of contents abstract specification erc-721 erc-20 erc-165 authentication traversal composable transfer function parameter format transferfrom/safetransferfrom functions do not transfer tokens owned by tokens erc-721 top-down composable erc-20 top-down composable erc-721 bottom-up composable erc-20 bottom-up composable notes rationale which kind of composable to use? explicit transfer parameters backwards compatibility reference implementation security considerations copyright abstract an extension of the erc-721 standard to enable erc-721 tokens to own other erc-721 tokens and erc-20 tokens. an extension of the erc-20 and erc-223 https://github.com/ethereum/eips/issues/223 standards to enable erc-20 and erc-223 tokens to be owned by erc-721 tokens. this specification covers four different kinds of composable tokens: erc998erc721 top-down composable tokens that receive, hold and transfer erc-721 tokens erc998erc20 top-down composable tokens that receive, hold and transfer erc-20 tokens erc998erc721 bottom-up composable tokens that attach themselves to other erc-721 tokens. erc998erc20 bottom-up composable tokens that attach themselves to erc-721 tokens. which map to an erc998erc721 top-down composable is an erc-721 token with additional functionality for owning other erc-721 tokens. an erc998erc20 top-down composable is an erc-721 token with additional functionality for owning erc-20 tokens. an erc998erc721 bottom-up composable is an erc-721 token with additional functionality for being owned by an erc-721 token. an erc998erc20 bottom-up composable is an erc-20 token with additional functionality for being owned by an erc-721 token. a top-down composable contract stores and keeps track of child tokens for each of its tokens. a bottom-up composable contract stores and keeps track of a parent token for each its tokens. with composable tokens it is possible to compose lists or trees of erc-721 and erc-20 tokens connected by ownership. any such structure will have a single owner address at the root of the structure that is the owner of the entire composition. the entire composition can be transferred with one transaction by changing the root owner. different composables, top-down and bottom-up, have their advantages and disadvantages which are explained in the rational section. it is possible for a token to be one or more kinds of composable token. a non-fungible token is compliant and composable of this eip if it implements one or more of the following interfaces: erc998erc721topdown erc998erc20topdown erc998erc721bottomup erc998erc20bottomup specification erc-721 erc998erc721 top-down, erc998erc20 top-down, and erc998erc721 bottom-up composable contracts must implement the erc-721 interface. erc-20 erc998erc20 bottom-up composable contracts must implement the erc-20 interface. erc-165 the erc-165 standard must be applied to each erc-998 interface that is used. authentication authenticating whether a user or contract can execute some action works the same for both erc998erc721 top-down and erc998erc721 bottom-up composables. a rootowner refers to the owner address at the top of a tree of composables and erc-721 tokens. authentication within any composable is done by finding the rootowner and comparing it to msg.sender, the return result of getapproved(tokenid) and the return result of isapprovedforall(rootowner, msg.sender). if a match is found then authentication passes, otherwise authentication fails and the contract throws. here is an example of authentication code: address rootowner = address(rootownerof(_tokenid)); require(rootowner == msg.sender || isapprovedforall(rootowner,msg.sender) || getapproved(tokenid) == msg.sender; the approve(address _approved, uint256 _tokenid) and getapproved(uint256 _tokenid) erc-721 functions are implemented specifically for the rootowner. this enables a tree of composables to be transferred to a new rootowner without worrying about which addresses have been approved in child composables, because any prior approves can only be used by the prior rootowner. here are example implementations: function approve(address _approved, uint256 _tokenid) external { address rootowner = address(rootownerof(_tokenid)); require(rootowner == msg.sender || isapprovedforall(rootowner,msg.sender)); rootownerandtokenidtoapprovedaddress[rootowner][_tokenid] = _approved; emit approval(rootowner, _approved, _tokenid); } function getapproved(uint256 _tokenid) public view returns (address) { address rootowner = address(rootownerof(_tokenid)); return rootownerandtokenidtoapprovedaddress[rootowner][_tokenid]; } traversal the rootowner of a composable is gotten by calling rootownerof(uint256 _tokenid) or rootownerofchild(address _childcontract, uint256 _childtokenid). these functions are used by top-down and bottom-up composables to traverse up the tree of composables and erc-721 tokens to find the rootowner. erc998erc721 top-down and bottom-up composables are interoperable with each other. it is possible for a top-down composable to own a bottom-up composable or for a top-down composable to own an erc-721 token that owns a bottom-up token. in any configuration calling rootownerof(uint256 _tokenid) on a composable will return the root owner address at the top of the ownership tree. it is important to get the traversal logic of rootownerof right. the logic for rootownerof is the same whether or not a composable is bottom-up or top-down or both. here is the logic: logic for rootownerof(uint256 _tokenid) if the token is a bottom-up composable and has a parent token then call rootownerof for the parent token. if the call was successful then the returned address is the rootowner. otherwise call rootownerofchild for the parent token. if the call was successful then the returned address is the rootowner. otherwise get the owner address of the token and that is the rootowner. otherwise call rootownerofchild for the token if the call was successful then the returned address is the rootowner. otherwise get the owner address of the token and that is the rootowner. calling rootownerofchild for a token means the following logic: // logic for calling rootownerofchild for a tokenid address tokenowner = ownerof(tokenid); address childcontract = address(this); bytes32 rootowner = erc998erc721(tokenowner).rootownerofchild(childcontract, tokenid); but understand that the real call to rootownerofchild should be made with assembly so that the code can check if the call failed and so that the staticcall opcode is used to ensure that no state is modified. tokens/contracts that implement the above authentication and traversal functionality are “composable aware”. composable transfer function parameter format composable functions that make transfers follow the same parameter format: from:to:what. for example the getchild(address _from, uint256 _tokenid, address _childcontract, uint256 _childtokenid) composable function transfers an erc-721 token from an address to a top-down composable. the _from parameter is the from, the _tokenid parameter is the to and the address _childcontract, uint256 _childtokenid parameters are the what. another example is the safetransferchild(uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid) function. the _fromtokenid is the from, the _to is the to and the address _childcontract, address _childtokenid parameters are the what. transferfrom/safetransferfrom functions do not transfer tokens owned by tokens in bottom-up and top-down composable contracts the transferfrom and safetransferfrom functions must throw if they are called directly to transfer a token that is owned by another token. the reason for this is that these functions do not explicitly specify which token owns a token to be transferred. see the rational section for more information about this. transferfrom/safetransferfrom functions must be used to transfer tokens that are owned by an address. erc-721 top-down composable erc-721 top-down composables act as containers for erc-721 tokens. erc-721 top-down composables are erc-721 tokens that can receive, hold and transfer erc-721 tokens. there are two ways to transfer a erc-721 token to a top-down composable: use the function safetransferfrom(address _from, address _to, uint256 _tokenid, bytes data) function. the _to argument is the top-down composable contract address. the bytes data argument holds the integer value of the top-down composable tokenid that the erc-721 token is transferred to. call approve in the erc-721 token contract for the top-down composable contract. then call getchild in the composable contract. the first ways is for erc-721 contracts that have a safetransferfrom function. the second way is for contracts that do not have this function such as cryptokitties. here is an example of transferring erc-721 token 3 from an address to top-down composable token 6: uint256 tokenid = 6; bytes memory tokenidbytes = new bytes(32); assembly { mstore(add(tokenidbytes, 32), tokenid) } erc721(contractaddress).safetransferfrom(useraddress, composableaddress, 3, tokenidbytes); every erc-721 top-down composable compliant contract must implement the erc998erc721topdown interface. the erc998erc721topdownenumerable and erc998erc20topdownenumerable interfaces are optional. pragma solidity ^0.4.24; /// @title `erc998erc721` top-down composable non-fungible token /// @dev see https://github.com/ethereum/eips/blob/master/eips/eip-998.md /// note: the erc-165 identifier for this interface is 0xcde244d9 interface erc998erc721topdown { /// @dev this emits when a token receives a child token. /// @param _from the prior owner of the token. /// @param _totokenid the token that receives the child token. event receivedchild( address indexed _from, uint256 indexed _totokenid, address indexed _childcontract, uint256 _childtokenid ); /// @dev this emits when a child token is transferred from a token to an address. /// @param _fromtokenid the parent token that the child token is being transferred from. /// @param _to the new owner address of the child token. event transferchild( uint256 indexed _fromtokenid, address indexed _to, address indexed _childcontract, uint256 _childtokenid ); /// @notice get the root owner of tokenid. /// @param _tokenid the token to query for a root owner address /// @return rootowner the root owner at the top of tree of tokens and erc-998 magic value. function rootownerof(uint256 _tokenid) public view returns (bytes32 rootowner); /// @notice get the root owner of a child token. /// @param _childcontract the contract address of the child token. /// @param _childtokenid the tokenid of the child. /// @return rootowner the root owner at the top of tree of tokens and erc-998 magic value. function rootownerofchild( address _childcontract, uint256 _childtokenid ) public view returns (bytes32 rootowner); /// @notice get the parent tokenid of a child token. /// @param _childcontract the contract address of the child token. /// @param _childtokenid the tokenid of the child. /// @return parenttokenowner the parent address of the parent token and erc-998 magic value /// @return parenttokenid the parent tokenid of _tokenid function ownerofchild( address _childcontract, uint256 _childtokenid ) external view returns ( bytes32 parenttokenowner, uint256 parenttokenid ); /// @notice a token receives a child token /// @param _operator the address that caused the transfer. /// @param _from the owner of the child token. /// @param _childtokenid the token that is being transferred to the parent. /// @param _data up to the first 32 bytes contains an integer which is the receiving parent tokenid. function onerc721received( address _operator, address _from, uint256 _childtokenid, bytes _data ) external returns(bytes4); /// @notice transfer child token from top-down composable to address. /// @param _fromtokenid the owning token to transfer from. /// @param _to the address that receives the child token /// @param _childcontract the erc-721 contract of the child token. /// @param _childtokenid the tokenid of the token that is being transferred. function transferchild( uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid ) external; /// @notice transfer child token from top-down composable to address. /// @param _fromtokenid the owning token to transfer from. /// @param _to the address that receives the child token /// @param _childcontract the erc-721 contract of the child token. /// @param _childtokenid the tokenid of the token that is being transferred. function safetransferchild( uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid ) external; /// @notice transfer child token from top-down composable to address. /// @param _fromtokenid the owning token to transfer from. /// @param _to the address that receives the child token /// @param _childcontract the erc-721 contract of the child token. /// @param _childtokenid the tokenid of the token that is being transferred. /// @param _data additional data with no specified format function safetransferchild( uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid, bytes _data ) external; /// @notice transfer bottom-up composable child token from top-down composable to other erc-721 token. /// @param _fromtokenid the owning token to transfer from. /// @param _tocontract the erc-721 contract of the receiving token /// @param _totokenid the receiving token /// @param _childcontract the bottom-up composable contract of the child token. /// @param _childtokenid the token that is being transferred. /// @param _data additional data with no specified format function transferchildtoparent( uint256 _fromtokenid, address _tocontract, uint256 _totokenid, address _childcontract, uint256 _childtokenid, bytes _data ) external; /// @notice get a child token from an erc-721 contract. /// @param _from the address that owns the child token. /// @param _tokenid the token that becomes the parent owner /// @param _childcontract the erc-721 contract of the child token /// @param _childtokenid the tokenid of the child token function getchild( address _from, uint256 _tokenid, address _childcontract, uint256 _childtokenid ) external; } rootownerof 1 /// @notice get the root owner of tokenid. /// @param _tokenid the token to query for a root owner address /// @return rootowner the root owner at the top of tree of tokens and erc-998 magic value. function rootownerof(uint256 _tokenid) public view returns (bytes32 rootowner); this function traverses token owners until the the root owner address of _tokenid is found. the first 4 bytes of rootowner contain the erc-998 magic value 0xcd740db5. the last 20 bytes contain the root owner address. the magic value is returned because this function may be called on contracts when it is unknown if the contracts have a rootownerof function. the magic value is used in such calls to ensure a valid return value is received. if it is unknown whether a contract has the rootownerof function then the first four bytes of the rootowner return value must be compared to 0xcd740db5. 0xcd740db5 is equal to: this.rootownerof.selector ^ this.rootownerofchild.selector ^ this.tokenownerof.selector ^ this.ownerofchild.selector; here is an example of a value returned by rootownerof. 0xcd740db50000000000000000e5240103e1ff986a2c8ae6b6728ffe0d9a395c59 rootownerofchild /// @notice get the root owner of a child token. /// @param _childcontract the contract address of the child token. /// @param _childtokenid the tokenid of the child. /// @return rootowner the root owner at the top of tree of tokens and erc-998 magic value. function rootownerofchild( address _childcontract, uint256 _childtokenid ) public view returns (bytes32 rootowner); this function traverses token owners until the the root owner address of the supplied child token is found. the first 4 bytes of rootowner contain the erc-998 magic value 0xcd740db5. the last 20 bytes contain the root owner address. the magic value is returned because this function may be called on contracts when it is unknown if the contracts have a rootownerof function. the magic value is used in such calls to ensure a valid return value is received. if it is unknown whether a contract has the rootownerofchild function then the first four bytes of the rootowner return value must be compared to 0xcd740db5. ownerofchild /// @notice get the parent tokenid of a child token. /// @param _childcontract the contract address of the child token. /// @param _childtokenid the tokenid of the child. /// @return parenttokenowner the parent address of the parent token and erc-998 magic value /// @return parenttokenid the parent tokenid of _tokenid function ownerofchild( address _childcontract, uint256 _childtokenid ) external view returns ( address parenttokenowner, uint256 parenttokenid ); this function is used to get the parent tokenid of a child token and get the owner address of the parent token. the first 4 bytes of parenttokenowner contain the erc-998 magic value 0xcd740db5. the last 20 bytes contain the parent token owner address. the magic value is returned because this function may be called on contracts when it is unknown if the contracts have a ownerofchild function. the magic value is used in such calls to ensure a valid return value is received. if it is unknown whether a contract has the ownerofchild function then the first four bytes of the parenttokenowner return value must be compared to 0xcd740db5. onerc721received /// @notice a token receives a child token /// @param _operator the address that caused the transfer. /// @param _from the prior owner of the child token. /// @param _childtokenid the token that is being transferred to the parent. /// @param _data up to the first 32 bytes contains an integer which is the receiving parent tokenid. function onerc721received( address _operator, address _from, uint256 _childtokenid, bytes _data ) external returns(bytes4); this is a function defined in the erc-721 standard. this function is called in an erc-721 contract when safetransferfrom is called. the bytes _data argument contains an integer value from 1 to 32 bytes long that is the parent tokenid that an erc-721 token is transferred to. the onerc721received function is how a top-down composable contract is notified that an erc-721 token has been transferred to it and what tokenid in the top-down composable is the parent tokenid. the return value for onerc721received is the magic value 0x150b7a02 which is equal to bytes4(keccak256(abi.encodepacked("onerc721received(address,address,uint256,bytes)"))). transferchild /// @notice transfer child token from top-down composable to address. /// @param _fromtokenid the owning token to transfer from. /// @param _to the address that receives the child token /// @param _childcontract the erc-721 contract of the child token. /// @param _childtokenid the tokenid of the token that is being transferred. function transferchild( uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid ) external; this function authenticates msg.sender and transfers a child token from a top-down composable to a different address. this function makes this call within it: erc721(_childcontract).transferfrom(this, _to, _childtokenid); safetransferchild 1 /// @notice transfer child token from top-down composable to address. /// @param _fromtokenid the owning token to transfer from. /// @param _to the address that receives the child token /// @param _childcontract the erc-721 contract of the child token. /// @param _childtokenid the tokenid of the token that is being transferred. function safetransferchild( uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid ) external; this function authenticates msg.sender and transfers a child token from a top-down composable to a different address. this function makes this call within it: erc721(_childcontract).safetransferfrom(this, _to, _childtokenid); safetransferchild 2 /// @notice transfer child token from top-down composable to address or other top-down composable. /// @param _fromtokenid the owning token to transfer from. /// @param _to the address that receives the child token /// @param _childcontract the erc721 contract of the child token. /// @param _childtokenid the tokenid of the token that is being transferred. /// @param _data additional data with no specified format, can be used to specify tokenid to transfer to function safetransferchild( uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid, bytes _data ) external; this function authenticates msg.sender and transfers a child token from a top-down composable to a different address or to a different top-down composable. a child token is transferred to a different top-down composable if the _to address is a top-down composable contract and bytes _data is supplied an integer representing the parent tokenid. this function makes this call within it: erc721(_childcontract).safetransferfrom(this, _to, _childtokenid, _data); transferchildtoparent /// @notice transfer bottom-up composable child token from top-down composable to other erc-721 token. /// @param _fromtokenid the owning token to transfer from. /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _childcontract the bottom-up composable contract of the child token. /// @param _childtokenid the token that is being transferred. /// @param _data additional data with no specified format function transferchildtoparent( uint256 _fromtokenid, address _tocontract, uint256 _totokenid, address _childcontract, uint256 _childtokenid, bytes _data ) external this function authenticates msg.sender and transfers a child bottom-up composable token from a top-down composable to a different erc-721 token. this function can only be used when the child token is a bottom-up composable token. it is designed to transfer a bottom-up composable token from a top-down composable to an erc-721 token (bottom-up style) in one transaction. this function makes this call within it: erc998erc721bottomup(_childcontract).transfertoparent( address(this), _tocontract, _totokenid, _childtokenid, _data ); getchild /// @notice get a child token from an erc-721 contract. /// @param _from the address that owns the child token. /// @param _tokenid the token that becomes the parent owner /// @param _childcontract the erc-721 contract of the child token /// @param _childtokenid the tokenid of the child token function getchild( address _from, uint256 _tokenid, address _childcontract, uint256 _childtokenid ) external; this function is used to transfer an erc-721 token when its contract does not have a safetransferchild(uint256 _fromtokenid, address _to, address _childcontract, uint256 _childtokenid, bytes _data) function. a transfer with this function is done in two steps: the owner of the erc-721 token calls approve or setapprovalforall in the erc-721 contract for the top-down composable contract. the owner of the erc-721 token calls getchild in the top-down composable contract for the erc-721 token. the getchild function must authenticate that msg.sender is the owner of the erc-721 token in the erc-721 contract or is approved or an operator of the erc-721 token in the erc-721 contract. erc-721 top-down composable enumeration optional interface for top-down composable enumeration: /// @dev the erc-165 identifier for this interface is 0xa344afe4 interface erc998erc721topdownenumerable { /// @notice get the total number of child contracts with tokens that are owned by tokenid. /// @param _tokenid the parent token of child tokens in child contracts /// @return uint256 the total number of child contracts with tokens owned by tokenid. function totalchildcontracts(uint256 _tokenid) external view returns(uint256); /// @notice get child contract by tokenid and index /// @param _tokenid the parent token of child tokens in child contract /// @param _index the index position of the child contract /// @return childcontract the contract found at the tokenid and index. function childcontractbyindex( uint256 _tokenid, uint256 _index ) external view returns (address childcontract); /// @notice get the total number of child tokens owned by tokenid that exist in a child contract. /// @param _tokenid the parent token of child tokens /// @param _childcontract the child contract containing the child tokens /// @return uint256 the total number of child tokens found in child contract that are owned by tokenid. function totalchildtokens( uint256 _tokenid, address _childcontract ) external view returns(uint256); /// @notice get child token owned by tokenid, in child contract, at index position /// @param _tokenid the parent token of the child token /// @param _childcontract the child contract of the child token /// @param _index the index position of the child token. /// @return childtokenid the child tokenid for the parent token, child token and index function childtokenbyindex( uint256 _tokenid, address _childcontract, uint256 _index ) external view returns (uint256 childtokenid); } erc-20 top-down composable erc-20 top-down composables act as containers for erc-20 tokens. erc-20 top-down composables are erc-721 tokens that can receive, hold and transfer erc-20 tokens. there are two ways to transfer erc-20 tokens to an erc-20 top-down composable: use the transfer(address _to, uint256 _value, bytes _data); function from the erc-223 contract. the _to argument is the erc-20 top-down composable contract address. the _value argument is how many erc-20 tokens to transfer. the bytes argument holds the integer value of the top-down composable tokenid that receives the erc-20 tokens. call approve in the erc-20 contract for the erc-20 top-down composable contract. then call geterc20(address _from, uint256 _tokenid, address _erc20contract, uint256 _value) from the erc-20 top-down composable contract. the first way is for erc-20 contracts that support the erc-223 standard. the second way is for contracts that do not. erc-20 top-down composables implement the following interface: /// @title `erc998erc20` top-down composable non-fungible token /// @dev see https://github.com/ethereum/eips/blob/master/eips/eip-998.md /// note: the erc-165 identifier for this interface is 0x7294ffed interface erc998erc20topdown { /// @dev this emits when a token receives erc-20 tokens. /// @param _from the prior owner of the token. /// @param _totokenid the token that receives the erc-20 tokens. /// @param _erc20contract the erc-20 contract. /// @param _value the number of erc-20 tokens received. event receivederc20( address indexed _from, uint256 indexed _totokenid, address indexed _erc20contract, uint256 _value ); /// @dev this emits when a token transfers erc-20 tokens. /// @param _tokenid the token that owned the erc-20 tokens. /// @param _to the address that receives the erc-20 tokens. /// @param _erc20contract the erc-20 contract. /// @param _value the number of erc-20 tokens transferred. event transfererc20( uint256 indexed _fromtokenid, address indexed _to, address indexed _erc20contract, uint256 _value ); /// @notice a token receives erc-20 tokens /// @param _from the prior owner of the erc-20 tokens /// @param _value the number of erc-20 tokens received /// @param _data up to the first 32 bytes contains an integer which is the receiving tokenid. function tokenfallback(address _from, uint256 _value, bytes _data) external; /// @notice look up the balance of erc-20 tokens for a specific token and erc-20 contract /// @param _tokenid the token that owns the erc-20 tokens /// @param _erc20contract the erc-20 contract /// @return the number of erc-20 tokens owned by a token from an erc-20 contract function balanceoferc20( uint256 _tokenid, address _erc20contract ) external view returns(uint256); /// @notice transfer erc-20 tokens to address /// @param _tokenid the token to transfer from /// @param _value the address to send the erc-20 tokens to /// @param _erc20contract the erc-20 contract /// @param _value the number of erc-20 tokens to transfer function transfererc20( uint256 _tokenid, address _to, address _erc20contract, uint256 _value ) external; /// @notice transfer erc-20 tokens to address or erc-20 top-down composable /// @param _tokenid the token to transfer from /// @param _value the address to send the erc-20 tokens to /// @param _erc223contract the `erc-223` token contract /// @param _value the number of erc-20 tokens to transfer /// @param _data additional data with no specified format, can be used to specify tokenid to transfer to function transfererc223( uint256 _tokenid, address _to, address _erc223contract, uint256 _value, bytes _data ) external; /// @notice get erc-20 tokens from erc-20 contract. /// @param _from the current owner address of the erc-20 tokens that are being transferred. /// @param _tokenid the token to transfer the erc-20 tokens to. /// @param _erc20contract the erc-20 token contract /// @param _value the number of erc-20 tokens to transfer function geterc20( address _from, uint256 _tokenid, address _erc20contract, uint256 _value ) external; } tokenfallback /// @notice a token receives erc-20 tokens /// @param _from the prior owner of the erc-20 tokens /// @param _value the number of erc-20 tokens received /// @param _data up to the first 32 bytes contains an integer which is the receiving tokenid. function tokenfallback(address _from, uint256 _value, bytes _data) external; this function comes from the erc-223 which is an extension of the erc-20 standard. this function is called on the receiving contract from the sending contract when erc-20 tokens are transferred. this function is how the erc-20 top-down composable contract gets notified that one of its tokens received erc-20 tokens. which token received erc-20 tokens is specified in the _data parameter. balanceoferc20 /// @notice look up the balance of erc-20 tokens for a specific token and erc-20 contract /// @param _tokenid the token that owns the erc-20 tokens /// @param _erc20contract the erc-20 contract /// @return the number of erc-20 tokens owned by a token from an erc-20 contract function balanceoferc20( uint256 _tokenid, address _erc20contract ) external view returns(uint256); gets the balance of erc-20 tokens owned by a token from a specific erc-20 contract. transfererc20 /// @notice transfer erc-20 tokens to address /// @param _tokenid the token to transfer from /// @param _value the address to send the erc-20 tokens to /// @param _erc20contract the erc-20 contract /// @param _value the number of erc-20 tokens to transfer function transfererc20( uint256 _tokenid, address _to, address _erc20contract, uint256 _value ) external; this is used to transfer erc-20 tokens from a token to an address. this function calls erc20(_erc20contract).transfer(_to, _value); this function must authenticate msg.sender. transfererc223 /// @notice transfer erc-20 tokens to address or erc-20 top-down composable /// @param _tokenid the token to transfer from /// @param _value the address to send the erc-20 tokens to /// @param _erc223contract the `erc-223` token contract /// @param _value the number of erc-20 tokens to transfer /// @param _data additional data with no specified format, can be used to specify tokenid to transfer to function transfererc223( uint256 _tokenid, address _to, address _erc223contract, uint256 _value, bytes _data ) external; this function is from the erc-223. it is used to transfer erc-20 tokens from a token to an address or to another token by putting an integer token value in the _data argument. this function must authenticate msg.sender. geterc20 /// @notice get erc-20 tokens from erc-20 contract. /// @param _from the current owner address of the erc-20 tokens that are being transferred. /// @param _tokenid the token to transfer the erc-20 tokens to. /// @param _erc20contract the erc-20 token contract /// @param _value the number of erc-20 tokens to transfer function geterc20( address _from, uint256 _tokenid, address _erc20contract, uint256 _value ) external; this function is used to transfer erc-20 tokens to an erc-20 top-down composable when an erc-20 contract does not have a transfererc223(uint256 _tokenid, address _to, address _erc223contract, uint256 _value, bytes _data) function. before this function can be used the erc-20 top-down composable contract address must be approved in the erc-20 contract to transfer the erc-20 tokens. this function must authenticate that msg.sender equals _from or has been approved in the erc-20 contract. erc-20 top-down composable enumeration optional interface for top-down composable enumeration: /// @dev the erc-165 identifier for this interface is 0xc5fd96cd interface erc998erc20topdownenumerable { /// @notice get the number of erc-20 contracts that token owns erc-20 tokens from /// @param _tokenid the token that owns erc-20 tokens. /// @return uint256 the number of erc-20 contracts function totalerc20contracts(uint256 _tokenid) external view returns(uint256); /// @notice get an erc-20 contract that token owns erc-20 tokens from by index /// @param _tokenid the token that owns erc-20 tokens. /// @param _index the index position of the erc-20 contract. /// @return address the erc-20 contract function erc20contractbyindex( uint256 _tokenid, uint256 _index ) external view returns(address); } erc-721 bottom-up composable erc-721 bottom-up composables are erc-721 tokens that attach themselves to other erc-721 tokens. erc-721 bottom-up composable contracts store the owning address of a token and the parent tokenid if any. /// @title `erc998erc721` bottom-up composable non-fungible token /// @dev see https://github.com/ethereum/eips/blob/master/eips/eip-998.md /// note: the erc-165 identifier for this interface is 0xa1b23002 interface erc998erc721bottomup { /// @dev this emits when a token is transferred to an erc-721 token /// @param _tocontract the contract the token is transferred to /// @param _totokenid the token the token is transferred to /// @param _tokenid the token that is transferred event transfertoparent( address indexed _tocontract, uint256 indexed _totokenid, uint256 _tokenid ); /// @dev this emits when a token is transferred from an erc-721 token /// @param _fromcontract the contract the token is transferred from /// @param _fromtokenid the token the token is transferred from /// @param _tokenid the token that is transferred event transferfromparent( address indexed _fromcontract, uint256 indexed _fromtokenid, uint256 _tokenid ); /// @notice get the root owner of tokenid. /// @param _tokenid the token to query for a root owner address /// @return rootowner the root owner at the top of tree of tokens and erc-998 magic value. function rootownerof(uint256 _tokenid) external view returns (bytes32 rootowner); /// @notice get the owner address and parent token (if there is one) of a token /// @param _tokenid the tokenid to query. /// @return tokenowner the owner address of the token /// @return parenttokenid the parent owner of the token and erc-998 magic value /// @return isparent true if parenttokenid is a valid parent tokenid and false if there is no parent tokenid function tokenownerof( uint256 _tokenid ) external view returns ( bytes32 tokenowner, uint256 parenttokenid, bool isparent ); /// @notice transfer token from owner address to a token /// @param _from the owner address /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _data additional data with no specified format function transfertoparent( address _from, address _tocontract, uint256 _totokenid, uint256 _tokenid, bytes _data ) external; /// @notice transfer token from a token to an address /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _to the address the token is transferred to. /// @param _tokenid the token that is transferred /// @param _data additional data with no specified format function transferfromparent( address _fromcontract, uint256 _fromtokenid, address _to, uint256 _tokenid, bytes _data ) external; /// @notice transfer a token from a token to another token /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _tokenid the token that is transferred /// @param _data additional data with no specified format function transferaschild( address _fromcontract, uint256 _fromtokenid, address _tocontract, uint256 _totokenid, uint256 _tokenid, bytes _data ) external; } rootownerof /// @notice get the root owner of tokenid. /// @param _tokenid the token to query for a root owner address /// @return rootowner the root owner at the top of tree of tokens and erc-998 magic value. function rootownerof(uint256 _tokenid) public view returns (bytes32 rootowner); this function traverses token owners until the the root owner address of _tokenid is found. the first 4 bytes of rootowner contain the erc-998 magic value 0xcd740db5. the last 20 bytes contain the root owner address. the magic value is returned because this function may be called on contracts when it is unknown if the contracts have a rootownerof function. the magic value is used in such calls to ensure a valid return value is received. if it is unknown whether a contract has the rootownerof function then the first four bytes of the rootowner return value must be compared to 0xcd740db5. 0xcd740db5 is equal to: this.rootownerof.selector ^ this.rootownerofchild.selector ^ this.tokenownerof.selector ^ this.ownerofchild.selector; here is an example of a value returned by rootownerof. 0xcd740db50000000000000000e5240103e1ff986a2c8ae6b6728ffe0d9a395c59 tokenownerof /// @notice get the owner address and parent token (if there is one) of a token /// @param _tokenid the tokenid to query. /// @return tokenowner the owner address of the token and erc-998 magic value. /// @return parenttokenid the parent owner of the token /// @return isparent true if parenttokenid is a valid parent tokenid and false if there is no parent tokenid function tokenownerof( uint256 _tokenid ) external view returns ( bytes32 tokenowner, uint256 parenttokenid, bool isparent ); this function is used to get the owning address and parent tokenid of a token if there is one stored in the contract. if isparent is true then tokenowner is the owning erc-721 contract address and parenttokenid is a valid parent tokenid. if isparent is false then tokenowner is a user address and parenttokenid does not contain a valid parent tokenid and must be ignored. the first 4 bytes of tokenowner contain the erc-998 magic value 0xcd740db5. the last 20 bytes contain the token owner address. the magic value is returned because this function may be called on contracts when it is unknown if the contracts have a tokenownerof function. the magic value is used in such calls to ensure a valid return value is received. if it is unknown whether a contract has the rootownerof function then the first four bytes of the tokenowner return value must be compared to 0xcd740db5. transfertoparent /// @notice transfer token from owner address to a token /// @param _from the owner address /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _data additional data with no specified format function transfertoparent( address _from, address _tocontract, uint256 _totokenid, uint256 _tokenid, bytes _data ) external; this function is used to transfer a token from an address to a token. msg.sender must be authenticated. this function must check that _totoken exists in _tocontract and throw if not. transferfromparent /// @notice transfer token from a token to an address /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _to the address the token is transferred to. /// @param _tokenid the token that is transferred /// @param _data additional data with no specified format function transferfromparent( address _fromcontract, uint256 _fromtokenid, address _to, uint256 _tokenid, bytes _data ) external; this function is used to transfer a token from a token to an address. msg.sender must be authenticated. this function must check that _fromcontract and _fromtokenid own _tokenid and throw not. transferaschild /// @notice transfer a token from a token to another token /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _tokenid the token that is transferred /// @param _data additional data with no specified format function transferaschild( address _fromcontract, uint256 _fromtokenid, address _tocontract, uint256 _totokenid, uint256 _tokenid, bytes _data ) external; this function is used to transfer a token from a token to another token. msg.sender must be authenticated. this function must check that _totoken exists in _tocontract and throw if not. this function must check that _fromcontract and _fromtokenid own _tokenid and throw if not. erc-721 bottom-up composable enumeration optional interface for bottom-up composable enumeration: /// @dev the erc-165 identifier for this interface is 0x8318b539 interface erc998erc721bottomupenumerable { /// @notice get the number of erc-721 tokens owned by parent token. /// @param _parentcontract the contract the parent erc-721 token is from. /// @param _parenttokenid the parent tokenid that owns tokens // @return uint256 the number of erc-721 tokens owned by parent token. function totalchildtokens( address _parentcontract, uint256 _parenttokenid ) external view returns (uint256); /// @notice get a child token by index /// @param _parentcontract the contract the parent erc-721 token is from. /// @param _parenttokenid the parent tokenid that owns the token /// @param _index the index position of the child token /// @return uint256 the child tokenid owned by the parent token function childtokenbyindex( address _parentcontract, uint256 _parenttokenid, uint256 _index ) external view returns (uint256); } erc-20 bottom-up composable erc-20 bottom-up composables are erc-20 tokens that attach themselves to erc-721 tokens, or are owned by a user address like standard erc-20 tokens. when owned by an erc-721 token, erc-20 bottom-up composable contracts store the owning address of a token and the parent tokenid. erc-20 bottom-up composables add several methods to the erc-20 and erc-223 interfaces allowing for querying the balance of parent tokens, and transferring tokens to, from, and between parent tokens. this functionality can be implemented by adding one additional mapping to track balances of tokens, in addition to the standard mapping for tracking user address balances. /// @dev this mapping tracks standard erc20/`erc-223` ownership, where an address owns /// a particular amount of tokens. mapping(address => uint) userbalances; /// @dev this additional mapping tracks erc-998 ownership, where an erc-721 token owns /// a particular amount of tokens. this tracks contractaddres => tokenid => balance mapping(address => mapping(uint => uint)) nftbalances; the complete interface is below. /// @title `erc998erc20` bottom-up composable fungible token /// @dev see https://github.com/ethereum/eips/blob/master/eips/eip-998.md /// note: the erc-165 identifier for this interface is 0xffafa991 interface erc998erc20bottomup { /// @dev this emits when a token is transferred to an erc-721 token /// @param _tocontract the contract the token is transferred to /// @param _totokenid the token the token is transferred to /// @param _amount the amount of tokens transferred event transfertoparent( address indexed _tocontract, uint256 indexed _totokenid, uint256 _amount ); /// @dev this emits when a token is transferred from an erc-721 token /// @param _fromcontract the contract the token is transferred from /// @param _fromtokenid the token the token is transferred from /// @param _amount the amount of tokens transferred event transferfromparent( address indexed _fromcontract, uint256 indexed _fromtokenid, uint256 _amount ); /// @notice get the balance of a non-fungible parent token /// @param _tokencontract the contract tracking the parent token /// @param _tokenid the id of the parent token /// @return amount the balance of the token function balanceoftoken( address _tokencontract, uint256 _tokenid ) external view returns (uint256 amount); /// @notice transfer tokens from owner address to a token /// @param _from the owner address /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _amount the amount of tokens to transfer function transfertoparent( address _from, address _tocontract, uint256 _totokenid, uint256 _amount ) external; /// @notice transfer token from a token to an address /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _to the address the token is transferred to /// @param _amount the amount of tokens to transfer function transferfromparent( address _fromcontract, uint256 _fromtokenid, address _to, uint256 _amount ) external; /// @notice transfer token from a token to an address, using `erc-223` semantics /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _to the address the token is transferred to /// @param _amount the amount of tokens to transfer /// @param _data additional data with no specified format, can be used to specify the sender tokenid function transferfromparenterc223( address _fromcontract, uint256 _fromtokenid, address _to, uint256 _amount, bytes _data ) external; /// @notice transfer a token from a token to another token /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _amount the amount tokens to transfer function transferaschild( address _fromcontract, uint256 _fromtokenid, address _tocontract, uint256 _totokenid, uint256 _amount ) external; } balanceoftoken /// @notice get the balance of a non-fungible parent token /// @param _tokencontract the contract tracking the parent token /// @param _tokenid the id of the parent token /// @return amount the balance of the token function balanceoftoken( address _tokencontract, uint256 _tokenid ) external view returns (uint256 amount); this function returns the balance of a non-fungible token. it mirrors the standard erc-20 method balanceof, but accepts the address of the parent token’s contract, and the parent token’s id. this method behaves identically to balanceof, but checks for ownership by erc-721 tokens rather than user addresses. transfertoparent /// @notice transfer tokens from owner address to a token /// @param _from the owner address /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _amount the amount of tokens to transfer function transfertoparent( address _from, address _tocontract, uint256 _totokenid, uint256 _amount ) external; this function transfers an amount of tokens from a user address to an erc-721 token. this function must ensure that the recipient contract implements erc-721 using the erc-165 supportsinterface function. this function should ensure that the recipient token actually exists, by calling ownerof on the recipient token’s contract, and ensuring it neither throws nor returns the zero address. this function must emit the transfertoparent event upon a successful transfer (in addition to the standard erc-20 transfer event!). this function must throw if the _from account balance does not have enough tokens to spend. transferfromparent /// @notice transfer token from a token to an address /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _to the address the token is transferred to /// @param _amount the amount of tokens to transfer function transferfromparent( address _fromcontract, uint256 _fromtokenid, address _to, uint256 _amount ) external; this function transfers an amount of tokens from an erc-721 token to an address. this function must emit the transferfromparent event upon a successful transfer (in addition to the standard erc-20 transfer event!). this function must throw if the balance of the sender erc-721 token is less than the _amount specified. this function must verify that the msg.sender owns the sender erc-721 token, and must throw otherwise. transferfromparenterc223 /// @notice transfer token from a token to an address, using `erc-223` semantics /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _to the address the token is transferred to /// @param _amount the amount of tokens to transfer /// @param _data additional data with no specified format, can be used to specify the sender tokenid function transferfromparenterc223( address _fromcontract, uint256 _fromtokenid, address _to, uint256 _amount, bytes _data ) external; this function transfers an amount of tokens from an erc-721 token to an address. this function has identical requirements to transferfromparent, except that it additionally must invoke tokenfallback on the recipient address, if the address is a contract, as specified by erc-223. transferaschild 1 /// @notice transfer a token from a token to another token /// @param _fromcontract the address of the owning contract /// @param _fromtokenid the owning token /// @param _tocontract the erc-721 contract of the receiving token /// @param _totoken the receiving token /// @param _amount the amount tokens to transfer function transferaschild( address _fromcontract, uint256 _fromtokenid, address _tocontract, uint256 _totokenid, uint256 _amount ) external; this function transfers an amount of tokens from an erc-721 token to another erc-721 token. this function must emit both the transferfromparent and transfertoparent events (in addition to the standard erc-20 transfer event!). this function must throw if the balance of the sender erc-721 token is less than the _amount specified. this function must verify that the msg.sender owns the sender erc-721 token, and must throw otherwise. this function must ensure that the recipient contract implements erc-721 using the erc-165 supportsinterface function. this function should ensure that the recipient token actually exists, by calling ownerof on the recipient token’s contract, and ensuring it neither throws nor returns the zero address. notes for backwards-compatibility, implementations must emit the standard erc-20 transfer event when a transfer occurs, regardless of whether the sender and recipient are addresses or erc-721 tokens. in the case that either sender or recipient are tokens, the corresponding parameter in the transfer event should be the contract address of the token. implementations must implement all erc-20 and erc-223 functions in addition to the functions specified in this interface. rationale two different kinds of composable (top-down and bottom-up) exist to handle different use cases. a regular erc-721 token cannot own a top-down composable, but it can own a bottom-up composable. a bottom-up composable cannot own a regular erc-721 but a top-down composable can own a regular erc-721 token. having multiple kinds of composables enable different token ownership possibilities. which kind of composable to use? if you want to transfer regular erc-721 tokens to non-fungible tokens, then use top-down composables. if you want to transfer non-fungible tokens to regular erc-721 tokens then use bottom-up composables. explicit transfer parameters every erc-998 transfer function includes explicit parameters to specify the prior owner and the new owner of a token. explicitly providing from and to is done intentionally to avoid situations where tokens are transferred in unintended ways. here is an example of what could occur if from was not explicitly provided in transfer functions: an exchange contract is an approved operator in a specific composable contract for user a, user b and user c. user a transfers token 1 to user b. at the same time the exchange contract transfers token 1 to user c (with the implicit intention to transfer from user a). user b gets token 1 for a minute before it gets incorrectly transferred to user c. the second transfer should have failed but it didn’t because no explicit from was provided to ensure that token 1 came from user a. backwards compatibility composables are designed to work with erc-721, erc-223 and erc-20 tokens. some older erc-721 contracts do not have a safetransferfrom function. the getchild function can still be used to transfer a token to an erc-721 top-down composable. if an erc-20 contract does not have the erc-223 function transfer(address _to, uint _value, bytes _data) then the geterc20 function can still be used to transfer erc-20 tokens to an erc-20 top-down composable. reference implementation an implementation can be found here: https://github.com/mattlockyer/composables-998 security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: matt lockyer , nick mudge , jordan schalm , sebastian echeverry , zainan victor zhou (@xinbenlv), "erc-998: composable non-fungible token [draft]," ethereum improvement proposals, no. 998, july 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-998. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-4430: described transactions ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-4430: described transactions a technique for contracts to provide a human-readable description of a transaction's side-effects. authors richard moore (@ricmoo), nick johnson (@arachnid) created 2021-11-07 discussion link https://ethereum-magicians.org/t/discussion-eip-4430-described-transactions/8762 table of contents abstract motivation specification rationale meta description entangling the contract address alternatives backwards compatibility reference implementation security considerations escaping text copyright abstract use a contract method to provide virtual functions which can generate a human-readable description at the same time as the machine-readable bytecode, allowing the user to agree to the human-readable component in a ui while the machine can execute the bytecode once accepted. motivation when using an ethereum wallet (e.g. metamask, clef, hardware wallets) users must accept a transaction before it can be submitted (or the user may decline). due to the complexity of ethereum transactions, wallets are very limited in their ability to provide insight into the effects of a transaction that the user is approving; outside special-cased support for common transactions such as erc20 transfers, this often amounts to asking the user to sign an opaque blob of binary data. this eip presents a method for dapp developers to enable a more comfortable user experience by providing wallets with a means to generate a better description about what the contract claims will happen. it does not address malicious contracts which wish to lie, it only addresses honest contracts that want to make their user’s life better. we believe that this is a reasonable security model, as transaction descriptions can be audited at the same time as contract code, allowing auditors and code reviewers to check that transaction descriptions are accurate as part of their review. specification the description (a string) and the matching execcode (bytecode) are generated simultaneously by evaluating the method on a contract: function eipxxxdescribe(bytes inputs, bytes32 reserved) view returns (string description, bytes execcode) the human-readable description can be shown in any client which supports user interaction for approval, while the execcode is the data that should be included in a transaction to the contract to perform that operation. the method must be executable in a static context, (i.e. any side effects, such as logx, sstore, etc.), including through indirect calls may be ignored. during evaluation, the address (i.e. to), caller (i.e. from), value, and gasprice must be the same as the values for the transaction being described, so that the code generating the description can rely on them. when executing the bytecode, best efforts should be made to ensure blockhash, number, timestamp and difficulty match the "latest" block. the coinbase should be the zero address. the method may revert, in which case the signing must be aborted. rationale meta description there have been many attempts to solve this problem, many of which attempt to examine the encoded transaction data or message data directly. in many cases, the information that would be necessary for a meaningful description is not present in the final encoded transaction data or message data. instead this eip uses an indirect description of the data. for example, the commit(bytes32) method of ens places a commitment hash on-chain. the hash contains the blinded name and address; since the name is blinded, the encoded data (i.e. the hash) no longer contains the original values and is insufficient to access the necessary values to be included in a description. by instead describing the commitment indirectly (with the original information intact: name, address and secret) a meaningful description can be computed (e.g. “commit to name for address (with secret)”) and the matching data can be computed (i.e. commit(hash(name, owner, secret))). this technique of blinded data will become much more popular with l2 solutions, which use blinding not necessarily for privacy, but for compression. entangling the contract address to prevent signed data being used across contracts, the contract address is entanlged into both the transaction implicitly via the to field. alternatives natspec and company are a class of more complex languages that attempt to describe the encoded data directly. because of the language complexity they often end up being quite large requiring entire runtime environments with ample processing power and memory, as well as additional sandboxing to reduce security concerns. one goal of this is to reduce the complexity to something that could execute on hardware wallets and other simple wallets. these also describe the data directly, which in many cases (such as blinded data), cannot adequately describe the data at all custom languages; due to the complexity of ethereum transactions, any language used would require a lot of expressiveness and re-inventing the wheel. the evm already exists (it may not be ideal), but it is there and can handle everything necessary. format strings (e.g. trustless signing ui protocol; format strings can only operate on the class of regular languages, which in many cases is insufficient to describe an ethereum transaction. this was an issue quite often during early attempts at solving this problem. the signtypeddata eip-712 has many parallels to what this eip aims to solve backwards compatibility this does not affect backwards compatibility. reference implementation i will add deployed examples by address and chain id. security considerations escaping text wallets must be careful when displaying text provided by contracts and proper efforts must be taken to sanitize it, for example, be sure to consider: html could be embedded to attempt to trick web-based wallets into executing code using the script tag (possibly uploading any private keys to a server) in general, extreme care must be used when rendering html; consider the ens names ricmoo.eth or ricmoo.eth, which if rendered without care would appear as ricmoo.eth, which it is not other marks which require escaping could be included, such as quotes ("), formatting (\n (new line), \f (form feed), \t (tab), any of many non-standard whitespaces), back-slassh (\) utf-8 has had bugs in the past which could allow arbitrary code execution and crashing renderers; consider using the utf-8 replacement character (or something) for code-points outside common planes or common sub-sets within planes homoglyphs attacks right-to-left mark may affect rendering many other things, deplnding on your environment copyright copyright and related rights waived via cc0. citation please cite this document as: richard moore (@ricmoo), nick johnson (@arachnid), "erc-4430: described transactions [draft]," ethereum improvement proposals, no. 4430, november 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4430. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2583: penalty for account trie misses ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-2583: penalty for account trie misses authors martin holst swende (@holiman) created 2020-02-21 discussion link https://ethereum-magicians.org/t/eip-2583-penalties-for-trie-misses/4190 table of contents simple summary abstract motivation specification detailed specification notes on call-derivatives note on selfdestruct clarifications: rationale determining the penalty backwards compatibility ether transfers layer 2 other test cases security considerations implementation alternative variants alt 1: insta-refunds alt 2: parent bail copyright simple summary this eip introduces a gas penalty for opcodes which access the account for trie non-existent accounts. abstract this eip adds a gas penalty for accesses to the account trie, where the address being looked up does not exist. non-existing accounts can be used in dos attacks, since they bypass cache mechanisms, thus creating a large discrepancy between ‘normal’ mode of execution and ‘worst-case’ execution of an opcode. motivation as the ethereum trie becomes more and more saturated, the number of disk lookups that a node is required to do in order to access a piece of state increases too. this means that checking e.g. extcodehash of an account at block 5 was inherently a cheaper operation that it is at, say 8.5m. from an implementation perspective, a node can (and does) use various caching mechanisms to cope with the problem, but there’s an inherent problem with caches: when they yield a ‘hit’, they’re great, but when they ‘miss’, they’re useless. this is attackable. by forcing a node to lookup non-existent keys, an attacker can maximize the number of disk lookups. sidenote: even if the ‘non-existence’ is cached, it’s trivial to use a new non-existent key the next time, and never hit the same non-existent key again. thus, caching ‘non-existence’ might be dangerous, since it will evict ‘good’ entries. so far, the attempts to handle this problem has been in raising the gas cost, e.g. eip-150, eip-1884. however, when determining gas-costs, a secondary problem that arises due to the large discrepancy between ‘happy-path’ and ‘notorious path’ – how do we determine the pricing? the ‘happy-path’, assuming all items are cached? doing so would that would underprice all trie-accesses, and could be dos-attacked. the ‘normal’ usage, based on benchmarks of actual usage? this is basically what we do now, but that means that intentionally notorious executions are underpriced – which constitutes a dos vulnerability. the ‘paranoid’ case: price everything as if caching did not exist? this would severely harm basically every contract due to the gas-cost increase. also, if the gas limits were raised in order to allow the same amount of computation as before, the notorious case could again be used for dos attacks. from an engineering point of view, a node implementor is left with few options: implement bloom filters for existence. this is difficult, not least because of the problems of reorgs, and the fact that it’s difficult to undo bloom filter modifications. implement flattened account databases. this is also difficult, both because of reorgs and also because it needs to be an additional data structure aside from the trie – we need the trie for consensus. so it’s an extra data structure of around 15g that needs to be kept in check. this is currently being pursued by the geth-team. this eip proposes a mechanism to alleviate the situation. specification we define the constant penalty as tbd (suggested 2000 gas). for opcodes which access the account trie, whenever the operation is invoked targeting an address which does not exist in the trie, then penalty gas is deducted from the available gas. detailed specification these are the opcodes which triggers lookup into the main account trie: opcode affected comment balance yes balance(nonexistent_addr) would incur penalty extcodehash yes extcodehash(nonexistent_addr) would incur penalty extcodecopy yes extcodecopy(nonexistent_addr) would incur penalty extcodesize yes extcodesize(nonexistent_addr) would incur penalty call yes see details below about call variants callcode yes see details below about call variants delegatecall yes see details below about call variants staticcall yes see details below about call variants selfdestruct no see details below. create no create destination not explicitly settable, and assumed to be nonexistent already. create2 no create destination not explicitly settable, and assumed to be nonexistent already. notes on call-derivatives a call triggers a lookup of the call destination address. the base cost for call is at 700 gas. a few other characteristics determine the actual gas cost of a call: if the call (or callcode) transfers value, an additional 9k is added as cost. 1.1 if the call destination did not previously exist, an additional 25k gas is added to the cost. this eip adds a second rule in the following way: if the call does not transfer value and the callee does not exist, then penalty gas is added to the cost. in the table below, value means non-zero value transfer, !value means zero value transfer, dest means destination already exists, or is a precompile !dest means destination does not exist and is not a precompile op value,dest value, !dest !value, dest !value, !dest call no change no change no change penalty callcode no change no change no change penalty delegatecall n/a n/a no change penalty staticcall n/a n/a no change penalty whether the rules of this eip is to be applied for regular ether-sends in transactions is tbd. see the ‘backwards compatibility’-section for some more discussion on that topic. note on selfdestruct the selfdestruct opcode also triggers an account trie lookup of the beneficiary. however, due to the following reasons, it has been omitted from having a penalty since it already costs 5k gas. clarifications: the base costs of any opcodes are not modified by the eip. the opcode selfbalance is not modified by this eip, regardless of whether the self address exists or not. rationale with this scheme, we could continue to price these operations based on the ‘normal’ usage, but gain protection from attacks that try to maximize disk lookups/cache misses. this eip does not modify anything regarding storage trie accesses, which might be relevant for a future eip. however, there are a few crucial differences. storage tries are typically small, and there’s a high cost to populate a storage trie with sufficient density for it to be in the same league as the account trie. if an attacker wants to use an existing large storage trie, e.g. some popular token, he would typically have to make a call to cause a lookup in that token – something like token.balanceof(). that adds quite a lot of extra gas-impediments, as each call is another 700 gas, plus gas for arguments to the call. determining the penalty a transaction with 10m gas can today cause ~14k trie lookups. a penalty of 1000would lower the number to ~5800 lookups, 41% of the original. a penalty of 2000would lower the number to ~3700 lookups, 26% of the original. a penalty of 3000would lower the number to ~2700 lookups, 20% of the original. a penalty of 4000would lower the number to ~2100 lookups, 15% of the original. there exists a roofing function for the penalty. since the penalty is deducted from gas, that means that a malicious contract can always invoke a malicious relay to perform the trie lookup. let’s refer to this as the ‘shielded relay’ attack. in such a scenario, the malicious would spend ~750 gas each call to relay, and would need to provide the relay with at least 700 gas to do a trie access. thus, the effective cost would be on the order of 1500. it can thus be argued that penalty above ~800 would not achieve better protection against trie-miss attacks. backwards compatibility this eip requires a hard-fork. ether transfers a regular transaction from one eoa to another, with value, is not affected. a transaction with 0 value, to a destination which does not exist, would be. this scenario is highly unlikely to matter, since such a transaction is useless – even during success, all it would accomplish would be to spend some gas. with this eip, it would potentially spend some more gas. layer 2 regarding layer-2 backward compatibility, this eip is a lot less disruptive than eips which modify the base cost of an opcode. for state accesses, there are seldom legitimate scenarios where a contract checks balance/extcodehash/extcodecopy/extcodesize of another contract b, and, if such b does not exist, continues the execution solidity remote calls example: when a remote call is made in solidity: recipient.invokemethod(1) solidity does a pre-flight extcodesize on recipient. if the pre-flight check returns 0, then revert(0,0) is executed, to stop the execution. if the pre-flight check returns non-zero, then the execution continues and the call is made. with this eip in place, the ‘happy-path’ would work as previously, and the ‘notorious’-path where recipient does not exist would cost an extra penalty gas, but the actual execution-flow would be unchanged. erc223 erc223 token standard is, at the time of writing, marked as ‘draft’, but is deployed and in use on mainnet today. the erc specifies that when a token transfer(_to,...) method is invoked, then: this function must transfer tokens and invoke the function tokenfallback (address, uint256, bytes) in _to, if _to is a contract. … note: the recommended way to check whether the _to is a contract or an address is to assemble the code of _to. if there is no code in _to, then this is an externally owned address, otherwise it’s a contract. the reference implementations from dexaran and openzeppelin both implement the iscontract check using an extcodesize invocation. this scenario could be affected, but in practice should not be. let’s consider the possibilities: the _to is a contract: then erc223 specifies that the function tokenfallback(...) is invoked. the gas expenditure for that call is at least700 gas. in order for the callee to be able to perform any action, best practice it to ensure that it has at least 2300 gas along with the call. in summary: this path requires there to be least 3000 extra gas available (which is not due to any penalty) the _to exists, but is no contract. the flow exits here, and is not affected by this eip the _to does not exist: a penalty is deducted. in summary, it would seem that erc223 should not be affected, as long as the penalty does not go above around 3000 gas. other the contract dentacoin would be affected. function transfer(address _to, uint256 _value) returns (bool success) { ... // omitted for brevity if (balances[msg.sender] >= _value && balances[_to] + _value > balances[_to]) { // check if sender has enough and for overflows balances[msg.sender] = safesub(balances[msg.sender], _value); // subtract dcn from the sender if (msg.sender.balance >= minbalanceforaccounts && _to.balance >= minbalanceforaccounts) { // check if sender can pay gas and if recipient could balances[_to] = safeadd(balances[_to], _value); // add the same amount of dcn to the recipient transfer(msg.sender, _to, _value); // notify anyone listening that this transfer took place return true; } else { balances[this] = safeadd(balances[this], dcnforgas); // pay dcnforgas to the contract balances[_to] = safeadd(balances[_to], safesub(_value, dcnforgas)); // recipient balance -dcnforgas transfer(msg.sender, _to, safesub(_value, dcnforgas)); // notify anyone listening that this transfer took place if(msg.sender.balance < minbalanceforaccounts) { if(!msg.sender.send(gasfordcn)) throw; // send eth to sender } if(_to.balance < minbalanceforaccounts) { if(!_to.send(gasfordcn)) throw; // send eth to recipient } } } else { throw; } } the contract checks _to.balance >= minbalanceforaccounts, and if the balance is too low, some dcn is converted to ether and sent to the _to. this is a mechanism to ease on-boarding, whereby a new user who has received some dcn can immediately create a transaction. before this eip: when sending dcn to a non-existing address, the additional gas expenditure would be: 9000 for an ether-transfer 25000 for a new account-creation (2300 would be refunded to the caller later) a total runtime gas-cost of 34k gas would be required to handle this case. after this eip: in addition to the 34k an additional penalty would be added. possibly two, since the reference implementation does the balance-check twice, but it’s unclear whether the compiled code would indeed perform the check twice. a total runtime gas-cost of 34k+penalty (or 34k + 2 * penalty) would be required to handle this case. it can be argued that the extra penalty of 2-3k gas can be considered marginal in relation to the other 34k gas already required to handle this. test cases the following cases need to be considered and tested: that during creation of a brand new contract, within the constructor, the penalty should not be applied for calls concerning the self-address. tbd: how the penalty is applied in the case of a contract which has performed a selfdestruct a) previously in the same call-context, b) previously in the same transaction, c) previously in the same block, for any variant of extcodehash(destructed), call(destructed), callcode(destructed) etc. the effects on a transaction with 0 value going to a non-existent account. security considerations see ‘backwards compatibility’ implementation not yet available. alternative variants alt 1: insta-refunds bump all trie accesses with penalty. extcodehash becomes 2700 instead of 700. if a trie access hit an existing item, immediately refund penalty (2k ) upside: this eliminates the ‘shielded relay’ attack downside: this increases the up-front cost of many ops (call/extcodehash/extcodesize/staticcall/extcodesize etc) which may break many contracts. alt 2: parent bail use penalty as described, but if a child context goes oog on the penalty, then the remainder is subtracted from the parent context (recursively). upside: this eliminates the ‘shielded relay’ attack downside: this breaks the current invariant that a child context is limited by whatever gas was allocated for it. however, the invariant is not totally thrown out, the new invariant becomes that it is limited to gas + penalty. this can be seen as ‘messy’ – since only some types of oog (penalties) becomes passed up the call chain, but not others, e.g. oog due to trying to allocate too much memory. there is a distinction, however: gas-costs which arise due to not-yet-consumed resources do not get passed to parent. for example: a huge allocation is not actually performed if there is insufficient gas. whereas gas-costs which arise due to already-consumed resources do get passed to parent; in this case the penalty is paid post-facto for a trie iteration. copyright copyright and related rights waived via cc0. citation please cite this document as: martin holst swende (@holiman), "eip-2583: penalty for account trie misses [draft]," ethereum improvement proposals, no. 2583, february 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2583. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7579: minimal modular smart accounts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7579: minimal modular smart accounts modular smart account interfaces and behavior for interoperability with minimal restrictions for accounts and modules authors zeroknots (@zeroknots), konrad kopp (@kopy-kat), taek lee (@leekt), fil makarov (@filmakarov), elim poon (@yaonam), lyu min (@rockmin216) created 2023-12-14 discussion link https://ethereum-magicians.org/t/erc-7579-minimal-modular-smart-accounts/17336 requires eip-165, eip-1271, eip-2771, eip-4337 table of contents abstract motivation specification definitions account modules rationale minimal approach extensions specifications backwards compatibility already deployed smart accounts reference implementation security considerations copyright abstract this proposal outlines the minimally required interfaces and behavior for modular smart accounts and modules to ensure interoperability across implementations. for accounts, the standard specifies execution, config and fallback interfaces as well as compliance to erc-165 and erc-1271. for modules, the standard specifies a core interface, module types and type-specific interfaces. motivation contract accounts are gaining adoption with many accounts being built using a modular architecture. these modular contract accounts (hereafter smart accounts) move functionality into external contracts (modules) in order to increase the speed and potential of innovation, to future-proof themselves and to allow customizability by developers and users. however, currently these smart accounts are built in vastly different ways, creating module fragmentation and vendor lock-in. there are several reasons for why standardizing smart accounts is very beneficial to the ecosystem, including: interoperability for modules to be used across different smart accounts interoperability for smart accounts to be used across different wallet applications and sdks preventing significant vendor lock-in for smart account users however, it is highly important that this standardization is done with minimal impact on the implementation logic of the accounts, so that smart account vendors can continue to innovate, while also allowing a flourishing, multi-account-compatible module ecosystem. as a result, the goal of this standard is to define the smart account and module interfaces and behavior that is as minimal as possible while ensuring interoperability between accounts and modules. 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. definitions smart account an erc-4337 compliant smart contract account that has a modular architecture. module a smart contract with self-contained smart account functionality. validator: a module used during the erc-4337 validation flow to determine if a useroperation is valid. executor: a module that can execute transactions on behalf of the smart account via a callback. fallback handler: a module that can extend the fallback functionality of a smart account. entrypoint a trusted singleton contract according to erc-4337 specifications. account validation this standard does not dictate how validator selection is implemented. however, should a smart account encode validator selection mechanisms in erc-4337 useroperation fields (i.e. userop.signature), the smart account must sanitize the affected values before invoking the validator. the smart account’s validateuserop function should return the return value of the validator. execution behavior to comply with this standard, smart accounts must implement the two interfaces below. if an account implementation elects to not support any of the execution methods, it must implement the function, but revert instead of complying with the specifications below. this is in order to avoid unpredictable behavior with fallbacks. interface iexecution { /** * @dev packing batched transactions in a struct saves gas on both erc-4337 and executor module flows */ struct execution { address target; uint256 value; bytes calldata; } /** * must execute a `call` to the target with the provided data and value * must allow erc-4337 entrypoint to be the sender and may allow `msg.sender == address(this)` * must revert if the call was not successful */ function execute(address target, uint256 value, bytes calldata) external returns (bytes memory result); /** * must execute a `call` to all the targets with the provided data and value for each target * must allow erc-4337 entrypoint to be the sender and may allow `msg.sender == address(this)` * must revert if any call was not successful */ function executebatch(execution[] calldata executions) external returns (bytes memory result); /** * must execute a `call` to the target with the provided data and value * must only allow installed executors to call this function * must revert if the call was not successful */ function executefromexecutor(address target, uint256 value, bytes calldata) external returns (bytes memory result); /** * must execute a `call` to all the targets with the provided data and value for each target * must only allow installed executors to call this function * must revert if any call was not successful */ function executebatchfromexecutor(execution[] calldata executions) external returns (bytes memory result); } /** * @dev implementing delegatecall execution on a smart account must be considered carefully and is not recommended in most cases */ interface iexecutionunsafe { /** * must execute a `delegatecall` to the target with the provided data * must allow erc-4337 entrypoint to be the sender and may allow `msg.sender == address(this)` * must revert if the call was not successful */ function executedelegatecall(address target, bytes data) external returns (bytes memory result); /** * must execute a `delegatecall` to the target with the provided data and value * must only allow installed executors to call this function * must revert if the call was not successful */ function executedelegatecallfromexecutor(address target, bytes data) external returns (bytes memory result); } account configurations to comply with this standard, smart accounts must implement the entire interface below. if an account implementation elects to not support any of the configuration methods, it must revert, in order to avoid unpredictable behavior with fallbacks. when installing or uninstalling a module on a smart account, the smart account: must enforce authorization control on the relevant install or uninstall function for the module type must call the relevant oninstall or onuninstall function on the module must pass the sanitized initialisation data to the module must emit the relevant event for the module type when storing an installed module, the smart account must ensure that there is a way to differentiate between module types. for example, the smart account should be able to implement access control that only allows installed executors, but not other installed modules, to call the executefromexecutor function. interface iaccountconfig { // validators // functions function installvalidator(address validator, bytes calldata data) external; function uninstallvalidator(address validator, bytes calldata data) external; function isvalidatorinstalled(address validator) external view returns (bool); // events event installvalidator(address validator); event uninstallvalidator(address validator); // executors // functions function installexecutor(address executor, bytes calldata data) external; function uninstallexecutor(address executor, bytes calldata data) external; function isexecutorinstalled(address executor) external view returns (bool); // events event installexecutor(address executor); event uninstallexecutor(address executor); // fallback handlers // functions function installfallback(address fallbackhandler, bytes calldata data) external; function uninstallfallback(address fallbackhandler, bytes calldata data) external; function isfallbackinstalled(address fallbackhandler) external view returns (bool); // events event installfallbackhandler(address fallbackhandler); event uninstallfallbackhandler(address fallbackhandler); } hooks hooks are an optional extension of this standard. smart accounts may use hooks to execute custom logic and checks before and/or after the smart accounts performs a single or batched execution. to comply with this optional extension, a smart account must implement the entire interface below and it: must enforce authorization control on the relevant install or uninstall function for hooks must call the oninstall or onuninstall function on the module when installing or uninstalling a hook must pass the sanitized initialisation data to the module when installing or uninstalling a hook must emit the relevant event for the hook must call the precheck function on a single and batched execution and on every install function may call the precheck function on uninstall functions must call the postcheck function after a single or batched execution as well as every install function may call the postcheck function on uninstall functions interface iaccountconfig_hook { // hooks // functions function installhook(address hook, bytes calldata data) external; function uninstallhook(address hook, bytes calldata data) external; function ishookinstalled(address hook) external view returns (bool); // events event installhook(address hook); event uninstallhook(address hook); } erc-1271 forwarding the smart account must implement the erc-1271 interface. the isvalidsignature function calls may be forwarded to a validator. if erc-1271 forwarding is implemented, the validator must be called with isvalidsignaturewithsender(address sender, bytes32 hash, bytes signature), where the sender is the msg.sender of the call to the smart account. should the smart account implement any validator selection encoding in the bytes signature parameter, the smart account must sanitize the parameter, before forwarding it to the validator. the smart account’s erc-1271 isvalidsignature function should return the return value of the validator that the request was forwarded to. fallback smart accounts may implement a fallback function that forwards the call to a fallback handler. if the smart account has a fallback handler installed, it: must implement authorization control must use call to invoke the fallback handler must utilize erc-2771 to add the original msg.sender to the calldata sent to the fallback handler erc-165 smart accounts must implement erc-165. however, for every interface function that reverts instead of implementing the functionality, the smart account must return false for the corresponding interface id. modules this standard separates modules into the following different types that each has a unique and incremental identifier, which should be used by accounts, modules and other entities to identify the module type: validation (type id: 1) execution (type id: 2) fallback (type id: 3) hooks (type id: 4) note: a single module can be of multiple types. modules must implement the following interface, which is used by smart accounts to install and uninstall modules: interface imodule { function oninstall(bytes calldata data) external; function onuninstall(bytes calldata data) external; function ismoduletype(uint256 typeid) external view returns(bool); } modules must revert if oninstall or onuninstall was unsuccessful. validators validators must implement the imodule and the ivalidator interface and have module type id: 1. interface ivalidator { /** * must validate that the signature is a valid signature of the userophash, and should return erc-4337's sig_validation_failed (and not revert) on signature mismatch */ function validateuserop(useroperation calldata userop, bytes32 userophash) external returns (uint256); /** * @dev `sender` is the address that sent the erc-1271 request to the smart account * * must return the erc-1271 `magic_value` if the signature is valid * must not modify state */ function isvalidsignaturewithsender(address sender, bytes32 hash, bytes calldata signature) external view returns (bytes4); } executors executors must implement the imodule interface and have module type id: 2. fallback handlers fallback handlers must implement the imodule interface and have module type id: 3. fallback handlers that implement authorization control, must not rely on msg.sender for authorization control but must use erc-2771 _msgsender() instead. hooks hooks must implement the imodule and the ihook interface and have module type id: 4. interface ihook { /** * may return arbitrary data in the `hookdata` return value */ function precheck(address msgsender, bytes calldata msgdata) external returns (bytes memory hookdata); /** * may validate the `hookdata` to validate transaction context of the `precheck` function */ function postcheck(bytes calldata hookdata) external returns (bool success); } rationale minimal approach smart accounts are a new concept and we are still learning about the best ways to build them. therefore, we should not be too opinionated about how they are built. instead, we should define the most minimal interfaces that allow for interoperability between smart accounts and modules to be used across different account implementations. our approach has been twofold: take learnings from existing smart accounts that have been used in production and from building interoperability layers between them ensure that the interfaces are as minimal and open to alternative architectures as possible extensions while we want to be minimal, we also want to allow for innovation and opinionated features. some of these features might also need to be standardized (for similar reasons as the core interfaces) even if not all smart accounts will implement them. to ensure that this is possible, we suggest for future standardization efforts to be done as extensions to this standard. this means that the core interfaces will not change, but that new interfaces can be added as extensions. these should be proposed as separate ercs, for example with the title [feature] extension for erc-7579. specifications multiple execution functions the erc-4337 validation phase validates the useroperation. modular validation requires the validation module to know the specific function being validated, especially for session key based validators. it needs to know: the function called by entrypoint on the account. the target address if it is an execution function. whether it is a call or delegatecall. whether it is a single or batched transaction. the function signature used in the interaction with the external contract. for a flourishing module ecosystem, compatibility across accounts is crucial. however, if smart accounts implement custom execute functions with different parameters and calldata offsets, it becomes much harder to build reusable modules across accounts. differentiating module types not differentiating between module types could present a security issue when enforcing authorization control. for example, if a smart account treats validators and executors as the same type of module, it could allow a validator to execute arbitrary transactions on behalf of the smart account. dependence on erc-4337 this standard has a strict dependency on erc-4337 for the validation flow. however, it is likely that smart account builders will want to build modular accounts in the future that do not use erc-4337 but, for example, a native account abstraction implementation on a rollup. once this starts to happen, the proposed upgrade path for this standard is to move the erc-4337 dependency into an extension (ie a separate erc) and to make it optional for smart accounts to implement. if it is required to standardize the validation flow for different account abstraction implementations, then these requirements could also be moved into separate extensions. the reason this is not done from the start is that currently, the only modular accounts that are being built are using erc-4337. therefore, it makes sense to standardize the interfaces for these accounts first and to move the erc-4337 dependency into an extension once there is a need for it. this is to maximize learnings about how modular accounts would look like when built on different account abstraction implementations. backwards compatibility already deployed smart accounts smart accounts that have already been deployed will most likely be able to implement this standard. if they are deployed as proxies, it is possible to upgrade to a new account implementation that is compliant with this standard. if they are deployed as non-upgradeable contracts, it might still be possible to become compliant, for example by adding a compliant adapter as a fallback handler, if this is supported. reference implementation a full interface of a smart account can be found in imsa.sol. security considerations needs more discussion. some initial considerations: implementing delegatecall executions on a smart account must be considered carefully. note that smart accounts implementing delegatecall must ensure that the target contract is safe, otherwise security vulnerabilities are to be expected. the oninstall and onuninstall functions on modules may lead to unexpected callbacks (i.e. reentrancy). account implementations should consider this by implementing adequate protection routines. furthermore, modules could maliciously revert on onuninstall to stop the account from uninstalling a module and removing it from the account. for modules types where only a single module is active at one time (e.g. fallback handlers), calling install* on a new module will not properly uninstall the previous module, unless this is properly implemented. this could lead to unexpected behavior if the old module is then added again with left over state. insufficient authorization control in fallback handlers can lead to unauthorized executions. malicious hooks may revert on precheck or postcheck, adding untrusted hooks may lead to a denial of service of the account. currently account configuration functions (e.g. installvalidator) are designed for single operations. an account could allow these to be called from address(this), creating the possibility to batch configuration operations. however, if an account implements greater authorization control for these functions since they are more sensitive, then these measures can be bypassed by nesting calls to configuration options in calls to self. copyright copyright and related rights waived via cc0. citation please cite this document as: zeroknots (@zeroknots), konrad kopp (@kopy-kat), taek lee (@leekt), fil makarov (@filmakarov), elim poon (@yaonam), lyu min (@rockmin216), "erc-7579: minimal modular smart accounts [draft]," ethereum improvement proposals, no. 7579, december 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7579. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. ethereum wallet developer preview | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search ethereum wallet developer preview posted by fabian vogelsteller on september 16, 2015 research & development we are happy to announce our very first developer-preview of the ethereum wallet ðapp. the point of this release is to gather feedback, squash bugs and, most importantly, get the code audited. please note that this is a developer-preview and not the final release. we advise you to be extremely careful putting large amount of ether in the wallet contracts. using the wallet on the mainnet should only be done with small amounts! as steve ballmer once said developers! developers! developers! and note that this is exactly our target audience, don’t blindly trust us and we ask (and advise!) you to take a thorough look through the code in the ethereum wallet repository! if you’d like to build the wallet yourself, you need to head over to the mist repository, use the wallet branch and follow the instructions in the readme. reporting issues if you have any issues with the wallet, open the developer console of the wallet (menu -> developer -> toggle console) and provide the logs from there and the terminal where you started geth or eth from. please report all issues to the wallet repository. how to run it? first download the binary for you os: (**note**: you can find newer releases here) mac os x windows 64bit windows 32bit (though we probably won't support bundled nodes with 32bit) linux 64bit linux 32bit this developer preview doesn't come bundled with a node, as there are a few things still to be finalised, so you still need to start one yourself. for this developer preview the supported clients are geth and eth. python is currently not supported because it does not have the required ipc interface to run the wallet. if you don't have one of these nodes installed yet, follow the instructions here or download a pre-build version. make sure you have updated to the latest version. and start a node by simply running: go: $ geth if you want to unlock an account to be able to transfer add --unlock , or start a console with $ geth attach and unlock it using the javascript interface: personal.unlockaccount(''). c++: $ eth it is important to note that the wallet is expecting a fully synced up node. in future versions of geth and eth the wallet will make use of the new eth_syncing method in the json rpc, allowing you to see a sync screen when you start the wallet. this feature is currently already supported by geth and eth on their develop branches. finally start the wallet by clicking the executable! running on a testnet if you want to try the wallet on a testnet you need to start your node with a different network id and probably a different data directory. to make sure the wallet can still connect to your node you manually need to set the ipc path: os x: $ geth --networkdid "1234" --datadir "/some/other/path" --ipcpath "/users//library/ethereum/geth.ipc" linux: $ geth --networkdid "1234" --datadir "/some/other/path" --ipcpath "/home//.ethereum/geth.ipc" additional you should probably provide your own genesis block using the --genesis flag. for more details about the flags see the wiki. after the node is started you can simple start the wallet again. note that you need to wait sometimes a bit, and click in the button in the corner. once you opened the wallet you will see a popup asking you to deploy a wallet contract on your testnet, which will be used as a code basis for your future wallet contracts. the main advantage is that it is much cheaper (1.8mio vs 180k gas). note: make sure you have the displayed account unlocked and has at least 1 ether. using the wallet the wallet allows you to create two types of wallets: a simple wallet - works like a normal account (additional features are being worked on; e.g. adding owners, setting a daily limit) a multisig wallet - allows you to add any number of owner accounts and set a daily limit. every owner can send money from that account as long as it is under the daily limit. if above you need the signatures of the required other owners. when operating on the main net make sure you write down / backup the wallet contract address! this address is required in case you need to reimport your wallet on a different computer or during backup/recovery. multisig if you want to send and amount which is over the daily limit, your other owners need to sign. this should mostly be done from another computer, though you could as well add accounts you have in the same node. if a pending request comes in it will look as follows: simply click approve and the transaction goes through. deleting wallets if you’d like to delete a wallet click the trash icon on the wallet page, next to the wallet name. after you typed the name of the wallet it will be deleted from the ðapp. if you wrote the address down, you can always re-import the wallet in the "add wallet" section. roadmap when everything works fine and we finished the binary integration we are planning to release a first official version in 1-2 weeks™ until then please file issues and discuss it on reddit! previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-2135: consumable interface (tickets, etc) ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-2135: consumable interface (tickets, etc) an interface extending erc-721 and erc-1155 for consumability, supporting use case such as an event ticket. authors zainan victor zhou (@xinbenlv) created 2019-06-23 requires eip-165, eip-721, eip-1155 table of contents abstract motivation specification rationale backwards compatibility test cases reference implementation security considerations copyright abstract this eip defines an interface to mark a digital asset as “consumable” and to react to its “consumption.” motivation digital assets sometimes need to be consumed. one of the most common examples is a concert ticket. it is “consumed” when the ticket-holder enters the concert hall. having a standard interface enables interoperability for services, clients, ui, and inter-contract functionalities on top of this use-case. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. any compliant contract must implement the following interface: pragma solidity >=0.7.0 <0.9.0; /// the erc-165 identifier of this interface is 0xdd691946 interface ierc2135 { /// @notice the consume function consumes a token every time it succeeds. /// @param _consumer the address of consumer of this token. it doesn't have /// to be the eoa or contract account that initiates the tx. /// @param _assetid the nft asset being consumed /// @param _data extra data passed in for consume for extra message /// or future extension. function consume( address _consumer, uint256 _assetid, uint256 _amount, bytes calldata _data ) external returns (bool _success); /// @notice the interface to check whether an asset is consumable. /// @param _consumer the address of consumer of this token. it doesn't have /// to be the eoa or contract account that initiates the tx. /// @param _assetid the nft asset being consumed. /// @param _amount the amount of the asset being consumed. function isconsumableby( address _consumer, uint256 _assetid, uint256 _amount ) external view returns (bool _consumable); /// @notice the event emitted when there is a successful consumption. /// @param consumer the address of consumer of this token. it doesn't have /// to be the eoa or contract account that initiates the tx. /// @param assetid the nft asset being consumed /// @param amount the amount of the asset being consumed. /// @param data extra data passed in for consume for extra message /// or future extension. event onconsumption( address indexed consumer, uint256 indexed assetid, uint256 amount, bytes data ); } if the compliant contract is an erc-721 or erc-1155 token, in addition to onconsumption, it must also emit the transfer / transfersingle event (as applicable) as if a token has been transferred from the current holder to the zero address if the call to consume method succeeds. supportsinterface(0xdd691946) must return true for any compliant contract, as per erc-165. rationale the function consume performs the consume action. this eip does not assume: who has the power to perform consumption under what condition consumption can occur it does, however, assume the asset can be identified in a uint256 asset id as in the parameter. a design convention and compatibility consideration is put in place to follow the erc-721 pattern. the event notifies subscribers whoever are interested to learn an asset is being consumed. to keep it simple, this standard intentionally contains no functions or events related to the creation of a consumable asset. this is because the creation of a consumable asset will need to make assumptions about the nature of an actual use-case. if there are common use-cases for creation, another follow up standard can be created. metadata associated to the consumables is not included the standard. if necessary, related metadata can be created with a separate metadata extension interface like erc721metadata from erc-721 we choose to include an address consumer for consume function and isconsumableby so that an nft may be consumed for someone other than the transaction initiator. we choose to include an extra _data field for future extension, such as adding crypto endorsements. we explicitly stay opinion-less about whether erc-721 or erc-1155 shall be required because while we design this eip with erc-721 and erc-1155 in mind mostly, we don’t want to rule out the potential future case someone use a different token standard or use it in different use cases. the boolean view function of isconsumableby can be used to check whether an asset is consumable by the _consumer. backwards compatibility this interface is designed to be compatible with erc-721 and nft of erc-1155. it can be tweaked to used for erc-20, erc-777 and fungible token of erc-1155. test cases describe("consumption", function () { it("should consume when minted", async function () { const faketokenid = "0x1234"; const { contract, addr1 } = await loadfixture(deployfixture); await contract.safemint(addr1.address, faketokenid); expect(await contract.balanceof(addr1.address)).to.equal(1); expect(await contract.ownerof(faketokenid)).to.equal(addr1.address); expect(await contract.isconsumableby(addr1.address, faketokenid, 1)).to.be.true; const tx = await contract.consume(addr1.address, faketokenid, 1, []); const receipt = await tx.wait(); const events = receipt.events.filter((x: any) => { return x.event == "onconsumption" }); expect(events.length).to.equal(1); expect(events[0].args.consumer).to.equal(addr1.address); expect(events[0].args.assetid).to.equal(faketokenid); expect(events[0].args.amount).to.equal(1); expect(await contract.balanceof(addr1.address)).to.equal(0); await expect(contract.ownerof(faketokenid)) .to.be.rejectedwith('erc721: invalid token id'); await expect(contract.isconsumableby(addr1.address, faketokenid, 1)) .to.be.rejectedwith('erc721: invalid token id'); }); }); describe("eip-165 identifier", function () { it("should match", async function () { const { contract } = await loadfixture(deployfixture); expect(await contract.get165()).to.equal("0xdd691946"); expect(await contract.supportsinterface("0xdd691946")).to.be.true; }); }); reference implementation a deployment of version 0x1002 has been deployed onto goerli testnet at address 0x3682bcd67b8a5c0257ab163a226fbe07bf46379b. find the reference contract verified source code on etherscan’s goerli site for the address above. security considerations compliant contracts should pay attention to the balance change when a token is consumed. when the contract is being paused, or the user is being restricted from transferring a token, the consumeability should be consistent with the transferral restriction. compliant contracts should also carefully define access control, particularlly whether any eoa or contract account may or may not initiate a consume method in their own use case. security audits and tests should be used to verify that the access control to the consume function behaves as expected. copyright copyright and related rights waived via cc0. citation please cite this document as: zainan victor zhou (@xinbenlv), "erc-2135: consumable interface (tickets, etc)," ethereum improvement proposals, no. 2135, june 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2135. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6047: erc-721 balance indexing via transfer event ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-6047: erc-721 balance indexing via transfer event mandates emitting the transfer event for erc-721 nfts during contract creation authors zainan victor zhou (@xinbenlv) created 2022-11-26 discussion link https://ethereum-magicians.org/t/eip-xxx-require-erc721-to-always-emit-transfer/11894 requires eip-721 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip extends erc-721 to allow the tracking and indexing of nfts by mandating that a pre-existing event be emitted during contract creation. erc-721 requires a transfer event to be emitted whenever a transfer or mint (i.e. transfer from 0x0) or burn (i.g. transfer to 0x0) occurs, except during contract creation. this eip mandates that compliant contracts emit a transfer event regardless of whether it occurs during or after contract creation. motivation erc-721 requires a transfer event to be emitted whenever a transfer or mint (i.e. transfer from 0x0) or burn (i.e. transfer to 0x0) occurs, except for during contract creation. due to this exception, contracts can mint nfts during contract creation without the event being emitted. unlike erc-721, the erc-1155 standard mandates events to be emitted regardless of whether such minting occurs during or outside of contract creation. this allows an indexing service or any off-chain service to reliably capture and account for token creation. this eip removes this exception granted by erc-721 and mandates emitting the transfer for erc-721 during contract creation. in this manner, indexers and off-chain applications can track token minting, burning, and transferring while relying only on erc-721’s transfer event log. 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. compliant contracts must implement erc-721 compliant contracts must emit a transfer event whenever a token is transferred, minted (i.e. transferred from 0x0), or burned (i.g. transferred to 0x0), including during contract creation. rationale using the existing transfer event instead of creating a new event (e.g. creation) allows this eip to be backward compatible with existing indexers.e backwards compatibility all contracts compliant with this eip are compliant with erc-721. however, not all contracts compliant with erc-721 are compliant with this eip. security considerations no new security concerns. copyright copyright and related rights waived via cc0. citation please cite this document as: zainan victor zhou (@xinbenlv), "erc-6047: erc-721 balance indexing via transfer event [draft]," ethereum improvement proposals, no. 6047, november 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6047. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. more thoughts on scripting and future-compatibility | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search more thoughts on scripting and future-compatibility posted by vitalik buterin on february 5, 2014 research & development my previous post introducing ethereum script 2.0 was met with a number of responses, some highly supportive, others suggesting that we switch to their own preferred stack-based / assembly-based / functional paradigm, and offering various specific criticisms that we are looking hard at. perhaps the strongest criticism this time came from sergio damian lerner, bitcoin security researcher, developer of qixcoin and to whom we are grateful for his analysis of dagger. sergio particularly criticizes two aspects of the change: the fee system, which is changed from a simple one-variable design where everything is a fixed multiple of the basefee, and the loss of the crypto opcodes. the crypto opcodes are the more important part of sergio’s argument, and i will handle that issue first. in ethereum script 1.0, the opcode set had a collection of opcodes that are specialized around certain cryptographic functions – for example, there was an opcode sha3, which would take a length and a starting memory index off the stack and then push the sha3 of the string taken from the desired number of blocks in memory starting from the starting index. there were similar opcodes for sha256and ripemd160 and there were also crypto opcodes oriented around secp256k1 elliptic curve operations. in es2, those opcodes are gone. instead, they are replaced by a fluid system where people will need to write sha256 in es manually (in practice, we would offer a commision or bounty for this), and then later on smart interpreters can seamlessly replace the sha256 es script with a plain old machine-code (or even hardware) version of sha256 of the sort that you use when you call sha256 in c++. from an outside view, es sha256 and machine code sha256 are indistinguishable; they both compute the same function and therefore make the same transformations to the stack, the only difference is that the latter is hundreds of times faster, giving us the same efficiency as if sha256 was an opcode. a flexible fee system can then also be implemented to make sha256 cheaper to accommodate its reduced computation time, ideally making it as cheap as an opcode is now. sergio, however, prefers a different approach: coming with lots of crypto opcodes out of the box, and using hard-forking protocol changes to add new ones if necessary further down the line. he writes: first, after 3 years of watching bitcoin closely i came to understand that a cryptocurrency is not a protocol, nor a contract, nor a computer-network. a cryptocurrency is a community. with the exception of a very few set of constants, such as the money supply function and the global balance, anything can be changed in the future, as long as the change is announced in advance. bitcoin protocol worked well until now, but we know that in the long term it will face scalability issues and it will need to change accordingly. short term benefits, such as the simplicity of the protocol and the code base, helped the bitcoin get worldwide acceptance and network effect. is the reference code of bitcoin version 0.8 as simple as the 0.3 version? not at all. now there are caches and optimizations everywhere to achieve maximum performance and higher dos security, but no one cares about this (and nobody should). a cryptocurrency is bootstrapped by starting with a simple value proposition that works in the short/mid term. this is a point that is often brought up with regard to bitcoin. however, the more i look at what is actually going on in bitcoin development, the more i become firmly set in my position that, with the exception of very early-stage cryptographic protocols that are in their infancy and seeing very low practical usage, the argument is absolutely false. there are currently many flaws in bitcoin that can be changed if only we had the collective will to. to take a few examples: the 1 mb block size limit. currently, there is a hard limit that a bitcoin block cannot have more than 1 mb of transactions in it – a cap of about seven transactions per second. we are starting to brush against this limit already, with about 250 kb in each block, and it’s putting pressure on transaction fees already. in most of bitcoin’s history, fees were around $0.01, and every time the price rose the default btc-denominated fee that miners accept was adjusted down. now, however, the fee is stuck at $0.08, and the developers are not adjusting it down arguably because adjusting the fee back down to $0.01 would cause the number of transactions to brush against the 1 mb limit. removing this limit, or at the very least setting it to a more appropriate value like 32 mb, is a trivial change; it is only a single number in the source code, and it would clearly do a lot of good in making sure that bitcoin continues to be used in the medium term. and yet, bitcoin developers have completely failed to do it. the op_checkmultisig bug. there is a well-known bug in the op_checkmultisig operator, used to implement multisig transactions in bitcoin, where it requires an additional dummy zero as an argument which is simply popped off the stack and not used. this is highly non-intuitive, and confusing; when i personally was working on implementing multisig for pybitcointools, i was stuck for days trying to figure out whether the dummy zero was supposed to be at the front or take the place of the missing public key in a 2-of-3 multisig, and whether there are supposed to be two dummy zeroes in a 1-of-3 multisig. eventually, i figured it out, but i would have figured it out much faster had the operation of theop_checkmultisig operator been more intuitive. and yet, the bug has not been fixed. the bitcoind client. the bitcoind client is well-known for being a very unwieldy and non-modular contraption; in fact, the problem is so serious that everyone looking to build a bitcoind alternative that is more scalable and enterprise-friendly is not using bitcoind at all, instead starting from scratch. this is not a core protocol issue, and theoretically changing the bitcoind client need not involve any hard-forking changes at all, but the needed reforms are still not being done. all of these problems are not there because the bitcoin developers are incompetent. they are not; in fact, they are very skilled programmers with deep knowledge of cryptography and the database and networking issues inherent in cryptocurrency client design. the problems are there because the bitcoin developers very well realize that bitcoin is a 10-billion-dollar train hurtling along at 400 kilometers per hour, and if they try to change the engine midway through and even the tiniest bolt comes loose the whole thing could come crashing to a halt. a change as simple as swapping the database back in march 2011 almost did. this is why in my opinion it is irresponsible to leave a poorly designed, non-future-proof protocol, and simply say that the protocol can be updated in due time. on the contrary, the protocol must be designed to have an appropriate degree of flexibility from the start, so that changes can be made by consensus to automatically without needing to update any software. now, to address sergio’s second issue, his main qualm with modifiable fees: if fees can go up and down, it becomes very difficult for contracts to set their own fees, and if a fee goes up unexpectedly then that may open up a vulnerability through which an attacker may even be able to force a contract to go bankrupt. i must thank sergio for making this point; it is something that i had not yet sufficiently considered, and we will need to think carefully about when making our design. however, his solution, manual protocol updates, is arguably no better; protocol updates that change fee structures can expose new economic vulnerabilities in contracts as well, and they are arguably even harder to compensate for because there are absolutely no restrictions on what content manual protocol updates can contain. so what can we do? first of all, there are many intermediate solutions between sergio’s approach – coming with a limited fixed set of opcodes that can be added to only with a hard-forking protocol change – and the idea i provided in the es2 blogpost of having miners vote on fluidly changing fees for every script. one approach might be to make the voting system more discrete, so that there would be a hard line between a script having to pay 100% fees and a script being “promoted” to being an opcode that only needs to pay a 20x cryptofee. this could be done via some combination of usage counting, miner voting, ether holder voting or other mechanisms. this is essentially a built-in mechanism for doing hardforks that does not technically require any source code updates to apply, making it much more fluid and non-disruptive than a manual hardfork approach. second, it is important to point out once again that the ability to efficiently do strong crypto is not gone, even from the genesis block; when we launch ethereum, we will create a sha256 contract, a sha3 contract, etc and “premine” them into pseudo-opcode status right from the start. so ethereum will come with batteries included; the difference is that the batteries will be included in a way that seamlessly allows for the inclusion of more batteries in the future. but it is important to note that i consider this ability to add in efficient optimized crypto ops in the future to be mandatory. theoretically, it is possible to have a “zerocoin” contract inside of ethereum, or a contract using cryptographic proofs of computation (scip) and fully homomorphic encryption so you can actually use ethereum as the “decentralized amazon ec2 instance” for cloud computing that many people now incorrectly believe it to be. once quantum computing comes out, we might need to move to contracts that rely on ntru; one sha4 or sha5 come out we might need to move to contracts that rely on them. once obfuscation technology matures, contracts will want to rely on that to store private data. but in order for all of that to be possible with anything less than a $30 fee per transaction, the underlying cryptography would need to be implemented in c++ or machine code, and there would need to be a fee structure that reduces the fee for the operations appropriately once the optimizations have been made. this is a challenge to which i do not see any easy answers, and comments and suggestions are very much welcome. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements ðξvcon-0 recap | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search ðξvcon-0 recap posted by george hallam on december 5, 2014 events day 1 monday 24th nov ðξv: mission and processes the first day of ðξvcon-0 kicked off early at 7am with the ethereum uk communications team arriving at the venue (ethereum dev ug’s workspace in kreuzberg, berlin) to set up the 4k high quality recording equipment and arrange the space for the event. after a quick coffee and croissant/pain au chocolat, everyone was ready for the first presentation “welcome! our mission: ðapps” which was delivered by gavin wood. gavin made it very clear within this presentation the need for decentralised applications in today’s society with two very powerful opening quotes, “progress has led to the concentration of power” and "our mission therefore is decentralisation”. following the presentation on ðapps, gavin invited everyone present to introduce themselves and explain their roles in ethereum. it was humbling to see how ethereum has attracted such a magnificent team of incredibly talented people from such a wide variety of backgrounds. next up, stephan tual gave a talk highlighting the important role of the uk based communications team in building a strong and populous ethereum community. he also touched on the streamlining of internal communications procedures to maximise ethereum's core team efficiency. with 81 ethereum meetup/hackathons taking place from tehran to new york and with over 6000 members worldwide, the ethereum community has grown exponentially over the past 11 months. still, there is always more to be done. with the inclusion of 4 new members to the team, new educational tools on the horizon and increased interaction with the community, stephan hopes ethereum can become a worldwide phenomenon as we move forward to the release of the genesis block. straight after stephan’s talk, sven ehlert gave an insightful presentation on how scrum and agile will be utilised to again maximise the efficiency of ethereum’s software development. this will be achieved by focusing on the key elements of the “product” that are needed for completion, and by applying incremental development goals with short deadlines for each of the individual developer teams (mist, c++, solidity etc). this will hopefully increase the overall output whilst breaking down what is a truly enormous project into manageable pieces. finally to cap off the first day, alex van de sande gave an update on mist, the ethereum go client’s ðapp navigator. as many of you will have seen in alex’s recent mist presentation, the ðapp navigator will be an incredibly useful and powerful tool for people looking to interact with ethereum and will really help make it accessible and easy to use by everyone from the outset which is of course important for swift adoption. day 2 tuesday 25th nov languages, ðapps & architecture after monday’s introduction and team updates, day 2 would focus strongly on the direction of ethereum’s languages, ðapp creation and architecture updates. gavin wood and christian reitwießner started off with a talk on the vision of the solidity language and the roadmap to its completion as it comes closer to a language that supports all features provided by the ethereum virtual machine. you can try solidity in your browser now. this was followed by a brief chat from gavin this time focusing on the importance of secure documentation in ðapp development. the concept is to intertwine documentation and code in solidity so that the documentation can be used by the client to alert the user of any significant actions that may take place as a consequence of running the code in certain smart contracts. marek kotewicz then gave an update on the javascript api in a workshop setting allowing a lot of to-and-fro with the audience. he explained how it works, how to use it with smart contracts and what tools will be available to enable its use and uptake in the future. after lunch, piotr zieliński presented on golem, a project that aims to use ethereum to coordinate a p2p distributed computation network for research use. participants of the network share their computing power and in return receive a token of worth, incentivising their continued participation. users can also access the resources to implement their own tasks and distribute them across the network. following piotr, sven elert took the stage again to speak further on optimising ethereum’s workflow using continuous integration. ci is a concept intended to improve the quality of whichever project it is being used with. though ethereum already uses ci, we wish to further refine the process as we move forward. to this end, sven introduced several new and different implementations to make the developers lives easier as the project moves forward. to finish off day 2, lefteris karapetsas gave an interesting presentation about using emacs for c++ ethereum development. he highlighted several plugins to use in order to improve workflow as well as the plugin he's working on for syntax highlighting on solidity for emacs. it is very cool to see personal projects increasing ethereum's team overall efficiency! day 3 wednesday 26th nov client comparisons and what is ethereum? wednesday’s presentation and panel content offered a great opportunity to get the whole team on the same page from a client perspective. with martin becze arriving from san francisco, we had representatives for each client ready for a panel talk later on in the day. the aim of panel was to increase the development team’s understanding of the different clients and highlight the minor differences between each client and how they implement the ethereum virtual machine. the morning commenced with vinay gupta leading a workshop which had everyone present trying to come up with a definitive answer to “what is ethereum?”. it turns out it’s not as easy as we thought! each person had a chance to stand up and offer their own personal 30 second definition on what ethereum is. the answers were diverse, and it was interesting to see how people changed their angle of approach depending on which audience the explanation was aimed at. following vinay’s workshop, martin becze brought everyone up to speed with node-ethereum a node.js project he has been working on with joseph chow in palo alto. the talk started by outlining the ethereumjs-lib and node-etheruem's architecture, then focused on areas where the client differs in structure from the other c++, go and python client implementations. jeff wilcke also gave a brief update on ethereum go client on the whiteboard before the panel discussion. the presentation space was then rearranged for the panel with gavin wood (ethereum c++), jeff wilcke (ethereum go), heiko hees (pythereum) and martin becze (node-ethereum). each took turns outlining how each client handles state transactions, moves account balances, runs the evm and saves data to accounts whilst handling sucides and out-of-gas exceptions. questions where then posed by the audience, discussions continued on late into the night as day 3 drew to a close. day 4 thursday 27th nov robustness and security though it is exceptionally useful to have a large suite of tools available for developers and users wanting to interact with ethereum, it means nothing if the security and robustness of the network are in anyway compromised. to this end, the ethereum team is working very hard to audit the software with several external partners and ensure network stability from the release of the genesis block onwards. to this end, sven ehlert, jutta steiner and heiko hees kicked off the morning with a workshop on the stress testing project. the goal of the project is to again use continuous integration and take it one step further. with ci, the dev team can test to make sure that each client will behave correctly when it executes a contract. in this respect it will simulate how clients would interact with the blockchain in the real world. this will allow us to understand how the network will behave if the clients have different properties. for instance clients with low bandwidth and less cpu power interacting with those with more resources available. the project pays special attention to how this will affect potential forks of the blockchain. later on, the team will simulate attacks on the ethereum blockchain and network to test its durability and resilience. after the workshop, christoph jenzsch presented on the why and how of unit testing in the ethereum project. in his talk, christoph described several different types of test that need to be carried out unit tests, integration tests and system tests. he also explained the different tools available to make it easy for every developer involved in ethereum to get working on the huge amount of testing that needs to be carried out before it’s released. next, jutta steiner took the stage to deliver a talk on “achieving security”. she explained how our approach to security is to initiate both an internal audit and a massive external audit with established software security firms, academics, blockchain research firms and companies interested in utilising ethereum all taking part. jutta is also working on a bounty program which will be open to the community rewarding those who test and explore the protocol and software. we’ll be releasing more information on this shortly if you wish to take part. after a quick lunch, alex leverington updated us on the vision and roadmap of the libp2p multi protocol network framework. the p2p networking protocol is geared towards security as it is entirely encrypted from end to end. he contrasted the ethereum network with the internet as we know it today, emphasising the difference between using ssl certificates and p2p anonymous networks. he also commented on ethereum’s 3 network protocols whisper, swarm and ethereum itself. all 3 protocols run on the same line, so framing/multiplexing is being used to stop them from interfering with each others bandwidth needs. a key point to take away from this is that other ðapps can potentially build their own protocols and use the multiplexing to optimise the connection as well. gavin followed up with a presentation on the what and why of whisper: the multi dht messaging system with routing privacy. consensus is expensive, and for things like pure communications there are more elegant solutions available than using blockchain tech, hence the need for whisper. to understand whisper in general, think transactions, but without the eventual archival, any necessity of being bound to what is said or automated execution & state change. he also talked about some specific use cases for whisper, such as ðapps that need to provide dark (plausible denial over perfect network traffic analysis) comms to two correspondents that know nothing of each other but a hash. this could be a ðapp for a whistleblower to communicate to a known journalist exchange some small amount of verifiable material and arrange between themselves for some other protocol (swarm, perhaps) to handle the bulk transfer. to finish off the day, daniel nagy bought us up to speed on swarm, ethereum’s decentralised file storage and transmission protocol specifically targeted toward static web content hosting. daniel also covered dht (distributed hash table kademlia). this will allow peers to connect to other peers distributed throughout the network instead of peer that are simply close to each other. by deterministically connecting to random peers, you know that each peer will have a better picture of the overall state of the network, increasing its viability. day 5 friday 28th nov blockchain theory and the future the fifth and final day of devcon 0! after a week of talking about the near future of ethereum’s development and completion, the last day would be focused on future iterations of ethereum and blockchain technology as a whole. vitalik buterin and vlad zamfir started off day five with a whiteboard presentation on ethereum 1.x. there are several problems that need to be solved as blockchain technology moves forward in the future scalability and blockchain interoperability being at the forefront of those issues. the idea of ethereum interacting with thousands of other blockchains is an attractive one, this in itself solves certain scalability problems in that work can distributed across many chains as opposed to bloating one central chain. gavin then joined vitalik and together they talked about the ethereum light-client. a light client protocol is especially important for ethereum as it will allow it to run on low capacity environments such as mobile phones, iot (internet of things) devices and browser extensions. the two explained the development process and usage of patricia merkle trees to implement it. expect the light client to be ready for the release of ethereum 1.0. after lunch, juan batiz-benet of filecoin/ipfs showed the audience the technology behind ipfs and bitswap. he also presented some ethereum/ipfs use cases such as content addressed files, ipns naming and high performance distributed filesystem and tool integration. gavin once again took the stage to reveal mix, the ethereum ide. mix is being developed in conjunction with alethzero and expected to be released in the next 12 to 18 months. it supports a rather amazing feature set, including documentation, compiler and debugger integration as you type, information on code health, valid invariant, code structure and code formatting, as well as variable values and assertion truth annotations. finally, vitalik wrapped up the event with a presentation showing some ideas for ethereum 2.0 (sharding, hypercubes) and thanked all of those who attended. overall, ðξvcon-0 was very enriching and worthwhile for everyone who attended. as expected, the eth dev team is now very much on the same page and ready to push forward to the release of the genesis block. all of the presentations from devcon 0 were recorded and are currently being edited together by our resident graphic designer/video editor ian meikle. starting on the 8th, a steady stream of content “the ðξvcon-0 series” will be added to the ethereum youtube channel. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-5023: shareable non-fungible token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-5023: shareable non-fungible token an interface for creating value-holding tokens shareable by multiple owners authors jarno marttila (@yaruno), martin moravek (@mmartinmo) created 2022-01-28 requires eip-165 table of contents abstract motivation specification rationale backwards compatibility reference implementation security considerations copyright abstract this eip standardizes an interface for non-fungible value-holding shareable tokens. shareability is accomplished by minting copies of existing tokens for new recipients. sharing and associated events allow the construction of a graph describing who has shared what to which party. motivation nft standards such as eip-721 and eip-1155 have been developed to standardize scarce digital resources. however, many non-fungible digital resources need not be scarce. we have attempted to capture positive externalities in ecosystems with new types of incentive mechanisms that exhibit anti-rival logic, serve as an unit of accounting and function as medium of sharing. we envision that shareable tokens can work both as incentives but also as representations of items that are typically digital in their nature and gain more value as they are shared. these requirements have set us to define shareable nfts and more specifically a variation of shareable nfts called non-transferable shareable nfts. these shareable nfts can be “shared” in the same way digital goods can be shared, at an almost zero technical transaction cost. we have utilized them to capture anti-rival value in terms of accounting positive externalities in an economic system. typical nft standards such as eip-721 and eip-1155 do not define a sharing modality. instead erc standards define interfaces for typical rival use cases such as token minting and token transactions that the nft contract implementations should fulfil. the ‘standard contract implementations’ may extend the functionalities of these standards beyond the definition of interfaces. the shareable tokens that we have designed and developed in our experiments are designed to be token standard compatible at the interface level. however the implementation of token contracts may contain extended functionalities to match the requirements of the experiments such as the requirement of ‘shareability’. in reflection to standard token definitions, shareability of a token could be thought of as re-mintability of an existing token to another party while retaining the original version of it. sharing is an interesting concept as it can be thought and perceived in different ways. for example, when we talk about sharing we can think about it is as digital copying, giving a copy of a digital resource while retaining a version by ourselves. sharing can also be fractional or sharing could be about giving rights to use a certain resource. the concept of shareability and the context of shareability can take different forms and one might use different types of implementatins for instances of shareable tokens. hence we haven’t restricted that the interface should require any specific token type. shareable tokens can be made non-transferable at the contract implementaiton level. doing so, makes them shareable non-transferable tokens. in the reference implementation we have distilled a general case from our use cases that defines a shareable non-transferable nfts using the shareable nft interface. we believe that the wider audience should benefit from an abstraction level higher definition for shareability, such as this interface implementation, that defines minimum amount of functions that would be implemented to satisfy the concept of shareability. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. /// note: the erc-165 identifier for this interface is 0xded6338b interface ierc5023 is ierc165 { /// @dev this emits when a token is shared, reminted and given to another wallet that isn't function caller event share(address indexed from, address indexed to, uint256 indexed tokenid, uint256 derivedfromtokenid); /// @dev shares, remints an existing token, gives a newly minted token a fresh token id, keeps original token at function callers possession and transfers newly minted token to receiver which should be another address than function caller. function share(address to, uint256 tokenidtobeshared) external returns(uint256 newtokenid); } the share event is expected to be emitted when function method share is succesfully called and a new token on basis of a given token id is minted and transferred to a recipient. rationale current nft standards define transferable non-fungible tokens, but not shareable non-fungible tokens. to be able to create shareable nfts we see that existing nft contracts could be extended with an interface which defines the basic principles of sharing, namely the event of sharing and the function method of sharing. definition of how transferability of tokens should be handled is left to the contract implementor. in case transfering is left enable shareable tokens behave similarily to the existing tokens, except when they are shared, a version of token is retained. in case transfering is disabled, shareable tokens become shareable non-transferable tokens, where they can be minted and given or shared to other people, but they cannot be transferred away. imagine that bob works together with alice on a project. bob earns an unique nft indicating that he has made effort to the project, but bob feels that his accomplishments are not only out of his own accord. bob wants to share his token with alice to indicate that also alice deserves recognition of having put effort on their project. bob initiates token sharing by calling share method on the contract which has his token and indicates which one of his tokens he wishes to share and to whom by passing address and token id parameters. a new token is minted for alice and a share event is initiated to communicate that it was bob whom shared his token to alice by logging addresses who shared a token id to whose address and which token id was this new token derived from. over time, a tree-like structures can be formed from the share event information. if bob shared to alice, and alice shared further to charlie and alice also shared to david a rudimentary tree structure forms out from sharing activity. this share event data can be later on utilized to gain more information of share activities that the tokens represent. b -> a -> c \ > d these tree structures can be further aggregated and collapsed to network representations e.g. social graphs on basis of whom has shared to whom over a span of time. e.g. if bob shared a token to alice, and alice has shared a different token to charlie and bob has shared a token to charlie, connections form between all these parties through sharing activities. b----a----c \_______/ backwards compatibility this proposal is backwards compatible with eip-721 and eip-1155. reference implementation following reference implementation demonstrates a general use case of one of our pilots. in this case a shareable non-transferable token represents a contribution done to a community that the contract owner has decided to merit with a token. contract owner can mint a merit token and give it to a person. this token can be further shared by the receiver to other parties for example to share the received merit to others that have participated or influenced his contribution. // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; import "./ierc5023.sol"; import "@openzeppelin/contracts/token/erc721/ierc721.sol"; import "@openzeppelin/contracts/token/erc721/ierc721receiver.sol"; import "@openzeppelin/contracts/utils/address.sol"; import "@openzeppelin/contracts/utils/context.sol"; import "@openzeppelin/contracts/utils/strings.sol"; import "@openzeppelin/contracts/utils/introspection/erc165.sol"; import "@openzeppelin/contracts/token/erc721/extensions/ierc721metadata.sol"; import "@openzeppelin/contracts/token/erc721/extensions/erc721uristorage.sol"; import "@openzeppelin/contracts/access/ownable.sol"; contract shareableerc721 is erc721uristorage, ownable, ierc5023 /* eip165 */ { string baseuri; uint256 internal _currentindex; constructor(string memory _name, string memory _symbol) erc721(_name, _symbol) {} function mint( address account, uint256 tokenid ) external onlyowner { _mint(account, tokenid); } function settokenuri( uint256 tokenid, string memory tokenuri ) external { _settokenuri(tokenid, tokenuri); } function setbaseuri(string memory baseuri_) external { baseuri = baseuri_; } function _baseuri() internal view override returns (string memory) { return baseuri; } function share(address to, uint256 tokenidtobeshared) external returns(uint256 newtokenid) { require(to != address(0), "erc721: mint to the zero address"); require(_exists(tokenidtobeshared), "shareableerc721: token to be shared must exist"); require(msg.sender == ownerof(tokenidtobeshared), "method caller must be the owner of token"); string memory _tokenuri = tokenuri(tokenidtobeshared); _mint(to, _currentindex); _settokenuri(_currentindex, _tokenuri); emit share(msg.sender, to, _currentindex, tokenidtobeshared); return _currentindex; } function transferfrom( address from, address to, uint256 tokenid ) public virtual override { revert('in this reference implementation tokens are not transferrable'); } function safetransferfrom( address from, address to, uint256 tokenid ) public virtual override { revert('in this reference implementation tokens are not transferrable'); } } security considerations reference implementation should not be used as is in production. there are no other security considerations related directly to implementation of this standard. copyright copyright and related rights waived via cc0. citation please cite this document as: jarno marttila (@yaruno), martin moravek (@mmartinmo), "erc-5023: shareable non-fungible token," ethereum improvement proposals, no. 5023, january 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5023. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-3009: transfer with authorization ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-3009: transfer with authorization authors peter jihoon kim (@petejkim), kevin britz (@kbrizzle), david knott (@davidlknott) created 2020-09-28 discussion link https://github.com/ethereum/eips/issues/3010 requires eip-20, eip-712 table of contents simple summary abstract motivation specification event use with web3 providers rationale unique random nonce, instead of sequential nonce valid after and valid before eip-712 backwards compatibility test cases implementation security considerations copyright simple summary a contract interface that enables transferring of fungible assets via a signed authorization. abstract a set of functions to enable meta-transactions and atomic interactions with erc-20 token contracts via signatures conforming to the eip-712 typed message signing specification. this enables the user to: delegate the gas payment to someone else, pay for gas in the token itself rather than in eth, perform one or more token transfers and other operations in a single atomic transaction, transfer erc-20 tokens to another address, and have the recipient submit the transaction, batch multiple transactions with minimal overhead, and create and perform multiple transactions without having to worry about them failing due to accidental nonce-reuse or improper ordering by the miner. motivation there is an existing spec, eip-2612, that also allows meta-transactions, and it is encouraged that a contract implements both for maximum compatibility. the two primary differences between this spec and eip-2612 are that: eip-2612 uses sequential nonces, but this uses random 32-byte nonces, and that eip-2612 relies on the erc-20 approve/transferfrom (“erc-20 allowance”) pattern. the biggest issue with the use of sequential nonces is that it does not allow users to perform more than one transaction at time without risking their transactions failing, because: dapps may unintentionally reuse nonces that have not yet been processed in the blockchain. miners may process the transactions in the incorrect order. this can be especially problematic if the gas prices are very high and transactions often get queued up and remain unconfirmed for a long time. non-sequential nonces allow users to create as many transactions as they want at the same time. the erc-20 allowance mechanism is susceptible to the multiple withdrawal attack/swc-114, and encourages antipatterns such as the use of the “infinite” allowance. the wide-prevalence of upgradeable contracts have made the conditions favorable for these attacks to happen in the wild. the deficiencies of the erc-20 allowance pattern brought about the development of alternative token standards such as the erc-777 and erc-677. however, they haven’t been able to gain much adoption due to compatibility and potential security issues. specification event event authorizationused( address indexed authorizer, bytes32 indexed nonce ); // keccak256("transferwithauthorization(address from,address to,uint256 value,uint256 validafter,uint256 validbefore,bytes32 nonce)") bytes32 public constant transfer_with_authorization_typehash = 0x7c7c6cdb67a18743f49ec6fa9b35f50d52ed05cbed4cc592e13b44501c1a2267; // keccak256("receivewithauthorization(address from,address to,uint256 value,uint256 validafter,uint256 validbefore,bytes32 nonce)") bytes32 public constant receive_with_authorization_typehash = 0xd099cc98ef71107a616c4f0f941f04c322d8e254fe26b3c6668db87aae413de8; /** * @notice returns the state of an authorization * @dev nonces are randomly generated 32-byte data unique to the authorizer's * address * @param authorizer authorizer's address * @param nonce nonce of the authorization * @return true if the nonce is used */ function authorizationstate( address authorizer, bytes32 nonce ) external view returns (bool); /** * @notice execute a transfer with a signed authorization * @param from payer's address (authorizer) * @param to payee's address * @param value amount to be transferred * @param validafter the time after which this is valid (unix time) * @param validbefore the time before which this is valid (unix time) * @param nonce unique nonce * @param v v of the signature * @param r r of the signature * @param s s of the signature */ function transferwithauthorization( address from, address to, uint256 value, uint256 validafter, uint256 validbefore, bytes32 nonce, uint8 v, bytes32 r, bytes32 s ) external; /** * @notice receive a transfer with a signed authorization from the payer * @dev this has an additional check to ensure that the payee's address matches * the caller of this function to prevent front-running attacks. (see security * considerations) * @param from payer's address (authorizer) * @param to payee's address * @param value amount to be transferred * @param validafter the time after which this is valid (unix time) * @param validbefore the time before which this is valid (unix time) * @param nonce unique nonce * @param v v of the signature * @param r r of the signature * @param s s of the signature */ function receivewithauthorization( address from, address to, uint256 value, uint256 validafter, uint256 validbefore, bytes32 nonce, uint8 v, bytes32 r, bytes32 s ) external; optional: event authorizationcanceled( address indexed authorizer, bytes32 indexed nonce ); // keccak256("cancelauthorization(address authorizer,bytes32 nonce)") bytes32 public constant cancel_authorization_typehash = 0x158b0a9edf7a828aad02f63cd515c68ef2f50ba807396f6d12842833a1597429; /** * @notice attempt to cancel an authorization * @param authorizer authorizer's address * @param nonce nonce of the authorization * @param v v of the signature * @param r r of the signature * @param s s of the signature */ function cancelauthorization( address authorizer, bytes32 nonce, uint8 v, bytes32 r, bytes32 s ) external; the arguments v, r, and s must be obtained using the eip-712 typed message signing spec. example: domainseparator := keccak256(abiencode( keccak256( "eip712domain(string name,string version,uint256 chainid,address verifyingcontract)" ), keccak256("usd coin"), // name keccak256("2"), // version 1, // chainid 0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48 // verifyingcontract )) with the domain separator, the typehash, which is used to identify the type of the eip-712 message being used, and the values of the parameters, you are able to derive a keccak-256 hash digest which can then be signed using the token holder’s private key. example: // transfer with authorization typehash := keccak256( "transferwithauthorization(address from,address to,uint256 value,uint256 validafter,uint256 validbefore,bytes32 nonce)" ) params := { from, to, value, validafter, validbefore, nonce } // receivewithauthorization typehash := keccak256( "receivewithauthorization(address from,address to,uint256 value,uint256 validafter,uint256 validbefore,bytes32 nonce)" ) params := { from, to, value, validafter, validbefore, nonce } // cancelauthorization typehash := keccak256( "cancelauthorization(address authorizer,bytes32 nonce)" ) params := { authorizer, nonce } // "‖" denotes concatenation. digest := keecak256( 0x1901 ‖ domainseparator ‖ keccak256(abiencode(typehash, params...)) ) { v, r, s } := sign(digest, privatekey) smart contract functions that wrap receivewithauthorization call may choose to reduce the number of arguments by accepting the full abi-encoded set of arguments for the receivewithauthorization call as a single argument of the type bytes. example: // keccak256("receivewithauthorization(address,address,uint256,uint256,uint256,bytes32,uint8,bytes32,bytes32)")[0:4] bytes4 private constant _receive_with_authorization_selector = 0xef55bec6; function deposit(address token, bytes calldata receiveauthorization) external nonreentrant { (address from, address to, uint256 amount) = abi.decode( receiveauthorization[0:96], (address, address, uint256) ); require(to == address(this), "recipient is not this contract"); (bool success, ) = token.call( abi.encodepacked( _receive_with_authorization_selector, receiveauthorization ) ); require(success, "failed to transfer tokens"); ... } use with web3 providers the signature for an authorization can be obtained using a web3 provider with the eth_signtypeddata{_v4} method. example: const data = { types: { eip712domain: [ { name: "name", type: "string" }, { name: "version", type: "string" }, { name: "chainid", type: "uint256" }, { name: "verifyingcontract", type: "address" }, ], transferwithauthorization: [ { name: "from", type: "address" }, { name: "to", type: "address" }, { name: "value", type: "uint256" }, { name: "validafter", type: "uint256" }, { name: "validbefore", type: "uint256" }, { name: "nonce", type: "bytes32" }, ], }, domain: { name: tokenname, version: tokenversion, chainid: selectedchainid, verifyingcontract: tokenaddress, }, primarytype: "transferwithauthorization", message: { from: useraddress, to: recipientaddress, value: amountbn.tostring(10), validafter: 0, validbefore: math.floor(date.now() / 1000) + 3600, // valid for an hour nonce: web3.utils.randomhex(32), }, }; const signature = await ethereum.request({ method: "eth_signtypeddata_v4", params: [useraddress, json.stringify(data)], }); const v = "0x" + signature.slice(130, 132); const r = signature.slice(0, 66); const s = "0x" + signature.slice(66, 130); rationale unique random nonce, instead of sequential nonce one might say transaction ordering is one reason why sequential nonces are preferred. however, sequential nonces do not actually help achieve transaction ordering for meta transactions in practice: for native ethereum transactions, when a transaction with a nonce value that is too-high is submitted to the network, it will stay pending until the transactions consuming the lower unused nonces are confirmed. however, for meta-transactions, when a transaction containing a sequential nonce value that is too high is submitted, instead of staying pending, it will revert and fail immediately, resulting in wasted gas. the fact that miners can also reorder transactions and include them in the block in the order they want (assuming each transaction was submitted to the network by different meta-transaction relayers) also makes it possible for the meta-transactions to fail even if the nonces used were correct. (e.g. user submits nonces 3, 4 and 5, but miner ends up including them in the block as 4,5,3, resulting in only 3 succeeding) lastly, when using different applications simultaneously, in absence of some sort of an off-chain nonce-tracker, it is not possible to determine what the correct next nonce value is if there exists nonces that are used but haven’t been submitted and confirmed by the network. under high gas price conditions, transactions can often “get stuck” in the pool for a long time. under such a situation, it is much more likely for the same nonce to be unintentionally reused twice. for example, if you make a meta-transaction that uses a sequential nonce from one app, and switch to another app to make another meta-transaction before the previous one confirms, the same nonce will be used if the app relies purely on the data available on-chain, resulting in one of the transactions failing. in conclusion, the only way to guarantee transaction ordering is for relayers to submit transactions one at a time, waiting for confirmation between each submission (and the order in which they should be submitted can be part of some off-chain metadata), rendering sequential nonce irrelevant. valid after and valid before relying on relayers to submit transactions for you means you may not have exact control over the timing of transaction submission. these parameters allow the user to schedule a transaction to be only valid in the future or before a specific deadline, protecting the user from potential undesirable effects that may be caused by the submission being made either too late or too early. eip-712 eip-712 ensures that the signatures generated are valid only for this specific instance of the token contract and cannot be replayed on a different network with a different chain id. this is achieved by incorporating the contract address and the chain id in a keccak-256 hash digest called the domain separator. the actual set of parameters used to derive the domain separator is up to the implementing contract, but it is highly recommended that the fields verifyingcontract and chainid are included. backwards compatibility new contracts benefit from being able to directly utilize eip-3009 in order to create atomic transactions, but existing contracts may still rely on the conventional erc-20 allowance pattern (approve/transferfrom). in order to add support for eip-3009 to existing contracts (“parent contract”) that use the erc-20 allowance pattern, a forwarding contract (“forwarder”) can be constructed that takes an authorization and does the following: extract the user and deposit amount from the authorization call receivewithauthorization to transfer specified funds from the user to the forwarder approve the parent contract to spend funds from the forwarder call the method on the parent contract that spends the allowance set from the forwarder transfer the ownership of any resulting tokens back to the user example: interface idefitoken { function deposit(uint256 amount) external returns (uint256); function transfer(address account, uint256 amount) external returns (bool); } contract depositforwarder { bytes4 private constant _receive_with_authorization_selector = 0xef55bec6; idefitoken private _parent; ierc20 private _token; constructor(idefitoken parent, ierc20 token) public { _parent = parent; _token = token; } function deposit(bytes calldata receiveauthorization) external nonreentrant returns (uint256) { (address from, address to, uint256 amount) = abi.decode( receiveauthorization[0:96], (address, address, uint256) ); require(to == address(this), "recipient is not this contract"); (bool success, ) = address(_token).call( abi.encodepacked( _receive_with_authorization_selector, receiveauthorization ) ); require(success, "failed to transfer to the forwarder"); require( _token.approve(address(_parent), amount), "failed to set the allowance" ); uint256 tokensminted = _parent.deposit(amount); require( _parent.transfer(from, tokensminted), "failed to transfer the minted tokens" ); uint256 remainder = _token.balanceof(address(this); if (remainder > 0) { require( _token.transfer(from, remainder), "failed to refund the remainder" ); } return tokensminted; } } test cases see eip3009.test.ts. implementation eip3009.sol abstract contract eip3009 is ierc20transfer, eip712domain { // keccak256("transferwithauthorization(address from,address to,uint256 value,uint256 validafter,uint256 validbefore,bytes32 nonce)") bytes32 public constant transfer_with_authorization_typehash = 0x7c7c6cdb67a18743f49ec6fa9b35f50d52ed05cbed4cc592e13b44501c1a2267; // keccak256("receivewithauthorization(address from,address to,uint256 value,uint256 validafter,uint256 validbefore,bytes32 nonce)") bytes32 public constant receive_with_authorization_typehash = 0xd099cc98ef71107a616c4f0f941f04c322d8e254fe26b3c6668db87aae413de8; mapping(address => mapping(bytes32 => bool)) internal _authorizationstates; event authorizationused(address indexed authorizer, bytes32 indexed nonce); string internal constant _invalid_signature_error = "eip3009: invalid signature"; function authorizationstate(address authorizer, bytes32 nonce) external view returns (bool) { return _authorizationstates[authorizer][nonce]; } function transferwithauthorization( address from, address to, uint256 value, uint256 validafter, uint256 validbefore, bytes32 nonce, uint8 v, bytes32 r, bytes32 s ) external { require(now > validafter, "eip3009: authorization is not yet valid"); require(now < validbefore, "eip3009: authorization is expired"); require( !_authorizationstates[from][nonce], "eip3009: authorization is used" ); bytes memory data = abi.encode( transfer_with_authorization_typehash, from, to, value, validafter, validbefore, nonce ); require( eip712.recover(domain_separator, v, r, s, data) == from, "eip3009: invalid signature" ); _authorizationstates[from][nonce] = true; emit authorizationused(from, nonce); _transfer(from, to, value); } } ierc20transfer.sol abstract contract ierc20transfer { function _transfer( address sender, address recipient, uint256 amount ) internal virtual; } eip712domain.sol abstract contract eip712domain { bytes32 public domain_separator; } eip712.sol library eip712 { // keccak256("eip712domain(string name,string version,uint256 chainid,address verifyingcontract)") bytes32 public constant eip712_domain_typehash = 0x8b73c3c69bb8fe3d512ecc4cf759cc79239f7b179b0ffacaa9a75d522b39400f; function makedomainseparator(string memory name, string memory version) internal view returns (bytes32) { uint256 chainid; assembly { chainid := chainid() } return keccak256( abi.encode( eip712_domain_typehash, keccak256(bytes(name)), keccak256(bytes(version)), address(this), bytes32(chainid) ) ); } function recover( bytes32 domainseparator, uint8 v, bytes32 r, bytes32 s, bytes memory typehashanddata ) internal pure returns (address) { bytes32 digest = keccak256( abi.encodepacked( "\x19\x01", domainseparator, keccak256(typehashanddata) ) ); address recovered = ecrecover(digest, v, r, s); require(recovered != address(0), "eip712: invalid signature"); return recovered; } } a fully working implementation of eip-3009 can be found in this repository. the repository also includes an implementation of eip-2612 that uses the eip-712 library code presented above. security considerations use receivewithauthorization instead of transferwithauthorization when calling from other smart contracts. it is possible for an attacker watching the transaction pool to extract the transfer authorization and front-run the transferwithauthorization call to execute the transfer without invoking the wrapper function. this could potentially result in unprocessed, locked up deposits. receivewithauthorization prevents this by performing an additional check that ensures that the caller is the payee. additionally, if there are multiple contract functions accepting receive authorizations, the app developer could dedicate some leading bytes of the nonce could as the identifier to prevent cross-use. when submitting multiple transfers simultaneously, be mindful of the fact that relayers and miners will decide the order in which they are processed. this is generally not a problem if the transactions are not dependent on each other, but for transactions that are highly dependent on each other, it is recommended that the signed authorizations are submitted one at a time. the zero address must be rejected when using ecrecover to prevent unauthorized transfers and approvals of funds from the zero address. the built-in ecrecover returns the zero address when a malformed signature is provided. copyright copyright and related rights waived via cc0. citation please cite this document as: peter jihoon kim (@petejkim), kevin britz (@kbrizzle), david knott (@davidlknott), "erc-3009: transfer with authorization [draft]," ethereum improvement proposals, no. 3009, september 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3009. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5656: mcopy memory copying instruction ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: core eip-5656: mcopy memory copying instruction an efficient evm instruction for copying memory areas authors alex beregszaszi (@axic), paul dworzanski (@poemm), jared wasinger (@jwasinger), casey detrio (@cdetrio), pawel bylica (@chfast), charles cooper (@charles-cooper) created 2021-02-01 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification input stack gas costs output stack semantics rationale backwards compatibility test cases security considerations copyright abstract provide an efficient evm instruction for copying memory areas. motivation memory copying is a basic operation, yet implementing it on the evm comes with overhead. this was recognised and alleviated early on with the introduction of the “identity” precompile, which accomplishes memory copying by the use of call’s input and output memory offsets. its cost is 15 + 3 * (length / 32) gas, plus the call overhead. the identity precompile was rendered ineffective by the raise of the cost of call to 700, but subsequently the reduction by eip-2929 made it slightly more economical. copying exact words can be accomplished with mload mstore or dup1 mload dup2 mstore, at a cost of at least 12 gas per word. this is fairly efficient if the offsets are known upfront and the copying can be unrolled. in case copying is implemented at runtime with arbitrary starting offsets, besides the control flow overhead, the offset will need to be incremented using 32 add, adding at least 6 gas per word. copying non-exact words is more tricky, as for the last partial word, both the source and destination needs to be loaded, masked, or’d, and stored again. this overhead is significant. one edge case is if the last “partial word” is a single byte, it can be efficiently stored using mstore8. as example use case, copying 256 bytes costs: at least 757 gas pre-eip-2929 using the identity precompile at least 157 gas post-eip-2929 using the identity precompile at least 96 gas using unrolled mload/mstore instructions 27 gas using this eip according to an analysis of blocks 10537502 to 10538702, roughly 10.5% of memory copies would have had improved performance with the availability of an mcopy instruction. memory copying is used by languages like solidity and vyper, where we expect this improvement to provide efficient means of building data structures, including efficient sliced access and copies of memory objects. having a dedicated mcopy instruction would also add forward protection against future gas cost changes to call instructions in general. having a special mcopy instruction makes the job of static analyzers and optimizers easier, since the effects of a call in general have to be fenced, whereas an mcopy instruction would be known to only have memory effects. even if special cases are added for precompiles, a future hard fork could change call effects, and so any analysis of code using the identity precompile would only be valid for a certain range of blocks. finally, we expect memory copying to be immensely useful for various computationally heavy operations, such as evm384, where it is identified as a significant overhead. specification the instruction mcopy is introduced at 0x5e. input stack stack value top 0 dst top 1 src top 2 length this ordering matches the other copying instructions, i.e. calldatacopy, returndatacopy. gas costs per yellow paper terminology, it should be considered part of the w_copy group of opcodes, and follow the gas calculation for w_copy in the yellow paper. while the calculation in the yellow paper should be considered the final word, for reference, as of time of this writing, that currently means its gas cost is: words_copied = (length + 31) // 32 g_verylow = 3 g_copy = 3 * words_copied + memory_expansion_cost gas_cost = g_verylow + g_copy output stack this instruction returns no stack items. semantics it copies length bytes from the offset pointed at src to the offset pointed at dst in memory. copying takes place as if an intermediate buffer was used, allowing the destination and source to overlap. if length > 0 and (src + length or dst + length) is beyond the current memory length, the memory is extended with respective gas cost applied. the gas cost of this instruction mirrors that of other wcopy instructions and is gverylow + gcopy * ceil(length / 32). rationale production implementation of exact-word memory copying and partial-word memory copying can be found in the solidity, vyper and fe compilers. with eip-2929 the call overhead using the identity precompile was reduced from 700 to 100 gas. this is still prohibitive for making the precompile a reasonable alternative again. backwards compatibility this eip introduces a new instruction which did not exist previously. already deployed contracts using this instruction could change their behaviour after this eip. test cases mcopy 0 32 32 copy 32 bytes from offset 32 to offset 0. pre (spaces included for readability): 0000000000000000000000000000000000000000000000000000000000000000 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f post: 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f 000102030405060708090a0b0c0d0e0f101112131415161718191a1b1c1d1e1f gas used: 6 mcopy 0 0 32 copy 32 bytes from offset 0 to offset 0. pre: 0101010101010101010101010101010101010101010101010101010101010101 post: 0101010101010101010101010101010101010101010101010101010101010101 gas used: 6 mcopy 0 1 8 copy 8 bytes from offset 1 to offset 0 (overlapping). pre: 000102030405060708 0000000000000000000000000000000000000000000000 post: 010203040506070808 0000000000000000000000000000000000000000000000 gas used: 6 mcopy 1 0 8 copy 8 bytes from offset 0 to offset 1 (overlapping). pre: 000102030405060708 0000000000000000000000000000000000000000000000 post: 00000102030405060708 00000000000000000000000000000000000000000000 gas used: 6 security considerations tba copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), paul dworzanski (@poemm), jared wasinger (@jwasinger), casey detrio (@cdetrio), pawel bylica (@chfast), charles cooper (@charles-cooper), "eip-5656: mcopy memory copying instruction [draft]," ethereum improvement proposals, no. 5656, february 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-5656. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-4524: safer erc-20 ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-4524: safer erc-20 extending erc-20 with erc165 and adding safetransfer (like erc-721 and erc-1155) authors william schwab (@wschwab) created 2021-12-05 discussion link https://ethereum-magicians.org/t/why-isnt-there-an-erc-for-safetransfer-for-erc20/7604 requires eip-20, eip-165 table of contents abstract motivation specification rationale backwards compatibility test cases reference implementation security considerations copyright abstract this standard extends erc-20 tokens with eip-165, and adds familiar functions from erc-721 and erc-1155 ensuring receiving contracts have implemented proper functionality. motivation eip-165 adds (among other things) the ability to tell if a target recipient explicitly signals compatibility with an erc. this is already used in the eips for nfts, erc-721 and erc-1155. in addition, eip-165 is a valuable building block for extensions on popular standards to signal implementation, a trend we’ve seen in a number of nft extensions. this eip aims to bring these innovations back to erc-20. the importance of eip-165 is perhaps felt most for app developers looking to integrate with a generic standard such as erc-20 or erc-721, while integrating newer innovations built atop these standards. an easy example would be token permits, which allow for a one-transaction approval and transfer. this has already been implemented in many popular erc-20 tokens using the erc-2612 standard or similar. a platform integrating erc-20 tokens has no easy way of telling if a particular token has implemented token permits or not. (as of this writing, erc-2612 does not require eip-165.) with eip-165, the app (or contracts) could query supportsinterface to see if the interfaceid of a particular eip is registered (in this case, eip-2612), allowing for easier and more modular functions interacting with erc-20 contracts. it is already common in nft extensions to include an eip-165 interface with a standard, we would argue this is at least in part due to the underlying erc-721 and erc-1155 standards integrating eip-165. our hope is that this extension to erc-20 would also help future extensions by making them easier to integrate. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. in order to be compliant with this eip, and erc-20-compliant contract must also implement the following functions: pragma solidity 0.8.10; import './ierc20.sol'; import './ierc165.sol'; // the eip-165 interfaceid for this interface is 0x534f5876 interface safererc-20 is ierc20, ierc165 { function safetransfer(address to, uint256 amount) external returns(bool); function safetransfer(address to, uint256 amount, bytes memory data) external returns(bool); function safetransferfrom(address from, address to, uint256 amount) external returns(bool); function safetransferfrom(address from, address to, uint256 amount, bytes memory data) external returns(bool); } safetransfer and safetransferfrom must transfer as expected to eoa addresses, and to contracts implementing erc20receiver and returning the function selector (0x4fc35859) when called, and must revert when transferring to a contract which either does not have erc20receiver implemented, or does not return the function selector when called. in addition, a contract accepting safe transfers must implement the following if it wishes to accept safe transfers, and must return the function selector (0x4fc35859): pragma solidity 0.8.10; import './ierc165.sol'; interface erc20receiver is ierc165 { function onerc20received( address _operator, address _from, uint256 _amount, bytes _data ) external returns(bytes4); } rationale this eip is meant to be minimal and straightforward. adding eip-165 to erc-20 is useful for a number of applications, and outside of a minimal amount of code increasing contract size, carries no downside. the safetransfer and safetransferfrom functions are well recognized from erc-721 and erc-1155, and therefore keeping identical naming conventions is reasonable, and the benefits of being able to check for implementation before transferring are as useful for erc-20 tokens as they are for erc-721 and erc-1155. another easy backport from eip721 and eip1155 might be the inclusion of a metadata uri for tokens, allowing them to easily reference logo and other details. this has not been included, both in order to keep this eip as minimal as possible, and because it is already sufficiently covered by eip-1046. backwards compatibility there are no issues with backwards compatibility in this eip, as the full suite of erc-20 functions is unchanged. test cases test cases have been provided in the implementation repo here. reference implementation a sample repo demonstrating an implementation of this eip has been created here. it is (as of this writing) in a dapptools environment, for details on installing and running dapptools see the dapptools repo. security considerations onerc20received is a callback function. callback functions have been exploited in the past as a reentrancy vector, and care should be taken to make sure implementations are not vulnerable. copyright copyright and related rights waived via cc0. citation please cite this document as: william schwab (@wschwab), "erc-4524: safer erc-20 [draft]," ethereum improvement proposals, no. 4524, december 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4524. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5485: legitimacy, jurisdiction and sovereignty ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5485: legitimacy, jurisdiction and sovereignty an interface for identifying the legitimacy, jurisdiction and sovereignty. authors zainan victor zhou (@xinbenlv) created 2022-08-17 discussion link https://ethereum-magicians.org/t/erc-5485-interface-for-legitimacy-jurisdiction-and-sovereignty/10425 requires eip-165, eip-5247 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract provide a way for compliant smart contracts to declare their legitimacy lineage, jurisdiction they observe, and sovereignty if they choose to not fall onto any jurisdiction. motivation today, smart contracts have no standard way to specify their legitimacy lineage, jurisdiction, or sovereignty relationship. the introduction of such a standard, supports better integration with today’s legal and regulative scenarios: it supports a regulative body to allow or deny interoperability with smart contracts. it also allows daos to clearly declare “self-sovereignty” by announcing via this interface by saying they do not assert legitimacy from any source other than themselves. a real-world example is that contracta represents an a company registered in a country, contractb represents a the secretary of state of the country, and contractc represents the supreme court of the country. another real example is a contract that declares “self-sovereignty” that doesn’t follow any jurisdiction. this interface supports both cases, providing a way to allow smart contracts to determine if they want to allow/prohibit interaction based on sovereignty. for example, a country might want to require any digital money service’s all smart contracts to observe their erc-5485 jurisdiction before they are allowed to operate money in their (real world) legal jurisdiction. another real world use-case is that in some jurisdiction e.g. in united states, if an token issuer choose to issue a token, they can try to petition sec to recognize their token as registered security, if approved, will gain legitimacy from sec. should they choose to petition commodity futures trading commission (cftc) to recognize them as a commodity, if approved, will gain legitimacy from cftc. on the other hand, a dao with a strong decentralized ideology might choose to only inter-operate with eoa or “self-sovereign” smart contracts to avoid being affected by any country. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. compliant contract musts implement the following interface. interface ierc5485 { /// a function that returns the source of legitimacy in an address /// /// @returns address of eoa or contract that grants legitimacy status to this contract. /// see specification #2 and #3 for more details. function sourceoflegitimacy() public view returns (address); /// a function that returns the sovereign jurisdiction in an address /// /// @returns address of eoa or contract that *ultimately* grants legitimacy status (root of legitimacy lineage). /// see specification #4 and #4 for more details. function jurisdiction() public view returns (address); } suppose a compliant contracta is deployed at address 0x and gains its legitimacy from another contract or external owned account (eoa) at 0x. in this case, it must return the 0x when being queried for sourceoflegitimacy(). for example. if contracta gains legitimacy from contractb, contractb gains legitimacy from contractc but contractc doesn’t gain legitimacy from anyone, contractc is considered the “jurisdiction” that both contractb and contracta observe. both contracta and contractb must return the address of contractc as the result of jurisdiction. a contract that matches any of the following cases is considered a “sovereign contract”: case 1: it does not implement this eip case 2: it implements this eip but return its own address. case 3: it implements this eip but return a zero address. any compliant contract must return its legitimacy sources chain up to the sovereign contract when queried by jurisdiction(). if contracta gains legitimacy from contractb, contracta must observe the contractb’s order to any of the following order type 1: execute a selfdestruct of contracta if contracta observes jurisdiction of contractc (a sovereignty), contracta must observe contractc’s order to any the following order type 1: execute a selfdestruct of contracta order type 2: execute any smart contract executable proposals as specified in erc-5247 todo determine whether to address “add/remove legitimacy” in this eip or leave it as a future eip rationale needs discussion. backwards compatibility needs discussion. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: zainan victor zhou (@xinbenlv), "erc-5485: legitimacy, jurisdiction and sovereignty [draft]," ethereum improvement proposals, no. 5485, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5485. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5679: token minting and burning ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-5679: token minting and burning an extension for minting and burning eip-20, eip-721, and eip-1155 tokens authors zainan victor zhou (@xinbenlv) created 2022-09-17 requires eip-20, eip-165, eip-721, eip-1155 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip introduces a consistent way to extend token standards for minting and burning. motivation minting and burning are typical actions for creating and destroying tokens. by establishing a consistent way to mint and burn a token, we complete the basic lifecycle. some implementations of eip-721 and eip-1155 have been able to use transfer methods or the-like to mint and burn tokens. however, minting and burning change token supply. the access controls of minting and burning also usually follow different rules than transfer. therefore, creating separate methods for burning and minting simplifies implementations and reduces security error. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. any contract complying with eip-20 when extended with this eip, must implement the following interface: // the eip-165 identifier of this interface is 0xd0017968 interface ierc5679ext20 { function mint(address _to, uint256 _amount, bytes calldata _data) external; function burn(address _from, uint256 _amount, bytes calldata _data) external; } any contract complying with eip-721 when extended with this eip, must implement the following interface: // the eip-165 identifier of this interface is 0xcce39764 interface ierc5679ext721 { function safemint(address _to, uint256 _id, bytes calldata _data) external; function burn(address _from, uint256 _id, bytes calldata _data) external; } any contract complying with eip-1155 when extended with this eip, must implement the following interface: // the eip-165 identifier of this interface is 0xf4cedd5a interface ierc5679ext1155 { function safemint(address _to, uint256 _id, uint256 _amount, bytes calldata _data) external; function safemintbatch(address to, uint256[] calldata ids, uint256[] calldata amounts, bytes calldata data) external; function burn(address _from, uint256 _id, uint256 _amount, bytes[] calldata _data) external; function burnbatch(address _from, uint256[] calldata ids, uint256[] calldata amounts, bytes calldata _data) external; } when the token is being minted, the transfer events must be emitted as if the token in the _amount for eip-20 and eip-1155 and token id being _id for eip-721 and eip-1155 were transferred from address 0x0 to the recipient address identified by _to. the total supply must increase accordingly. when the token is being burned, the transfer events must be emitted as if the token in the _amount for eip-20 and eip-1155 and token id being _id for eip-721 and eip-1155 were transferred from the recipient address identified by _to to the address of 0x0. the total supply must decrease accordingly. safemint must implement the same receiver restrictions as safetransferfrom as defined in eip-721 and eip-1155. it’s recommended for the client to implement eip-165 identifiers as specified above. rationale it’s possible that the interface be consolidated to the same as eip-1155 which is always bearing _amount field, regardless of whether it’s a eip-20, eip-721 or eip-1155. but we choose that each erc token should have their own standard way of representing the amount of token to follow the same way of _id and _amount in their original token standard. we have chosen to identify the interface with eip-165 identifiers each individually, instead of having a single identifier because the signatures of interface are different. we have chosen not to create new events but to require the usage of existing transfer event as required by eip-20 eip-721 and eip-1155 for maximum compatibility. we have chosen to add safemintbatch and burnbatch methods for eip-1155 but not for eip-721 to follow the convention of eip-721 and eip-1155 respectively. we have not add extension for eip-777 because it already handles minting and burning. backwards compatibility this eip is designed to be compatible for eip-20, eip-721 and eip-1155 respectively. security considerations this eip depends on the security soundness of the underlying book keeping behavior of the token implementation. in particular, a token contract should carefully design the access control for which role is granted permission to mint a new token. failing to safe guard such behavior can cause fraudulent issuance and an elevation of total supply. the burning should also carefully design the access control. typically only the following two roles are entitled to burn a token: role 1. the current token holder role 2. an role with special privilege. either role 1 or role 2 or a consensus between the two are entitled to conduct the burning action. however as author of this eip we do recognize there are potentially other use case where a third type of role shall be entitled to burning. we keep this eip less opinionated in such restriction but implementors should be cautious about designing the restriction. copyright copyright and related rights waived via cc0. citation please cite this document as: zainan victor zhou (@xinbenlv), "erc-5679: token minting and burning," ethereum improvement proposals, no. 5679, september 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5679. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. ether purchase troubleshooting | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search ether purchase troubleshooting posted by vitalik buterin on july 23, 2014 organizational although we hope that the ether purchasing experience goes smoothly for everyone, we recognize that there will always be situations where things do not quite go as planned. perhaps your internet connection dies in the middle of your purchase. perhaps you accidentally click a back button or some link or simply hit refresh while the purchase is in progress. perhaps you forgot to download your wallet. perhaps you think you may have forgotten your password, and you want to make sure you have it down correctly. for all of these situations, the user experience is unfortunately going to be a bit more tricky than simply downloading a web app; a bit of command line action with a python script will be required. first of all, let's go over downloading the python script. to get the script installed, download the zip archive from here, and unpack it. then, navigate to the directory, and you should see a number of files, including pyethsaletool.py. at this point, open up a command line in this directory. run python pyethsaletool.py, and you should see a list of help instructions. now, let's go over the most common potential issues one by one. 1) i forgot to download my wallet before closing the browser tab. you should receive a backup of your wallet in your email. if you entered a fake email address, and at the same time forgot to download your wallet, then unfortunately you have no recourse. 2) i want to make sure that my ether was actually purchased. run python pyethsaletool.py list -w /path/to/your/wallet.json, substituting the path with the path where you downloaded your wallet to. you should see a record of your purchase. if not, then run python pyethsaletool.py getbtcaddress -w /path/to/your/wallet.json and look up the address on blockchain.info. if there is a nonzero balance, you are in situation #4. 3) i want to make sure that i remember my password. run python pyethsaletool.py getbtcprivkey -w /path/to/your/wallet.json, substituting the path. when it prompts you for the password enter it, and see whether you get an error. if you get an error to do with pkcs7 padding, you entered the wrong password; if you get a btc private key out (ie. a sequence of 51 characters starting with a 5), then you're fine. 4) i sent my btc into the intermediate address, but it never made it to the exodus. run python pyethsaletool.py getbtcprivkey -w /path/to/your/wallet.json, substituting the path appropriately. then, import this private key into the blockchain.info wallet or kryptokit. alternatively, you may also run python pyethsaletool.py finalize -w /path/to/your/wallet.json to finish the purchasing process through python. 5) i want to make sure i will be able to access my ether later. run python pyethsaletool.py getethprivkey -w /path/to/your/wallet.json, substituting the path. then, download pyethereum, install it, and use pyethtool privtoaddr c85ef7d79691fe79573b1a7064c19c1a9819ebdbd1faaab1a8ec92344438aaf4, substituting in the ethereum privkey that you got from the first step. if the address that you get matches the address that you saw when you were purchasing ether, then you know that you have your ethereum private key. 6) i sent more btc into the intermediate address after the web app finalized. this situation is identical to #4. you can recover the btc or finalize it at your leisure. if you have any other issues, please ask them in the comments and they will be added to this article. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-6093: custom errors for commonly-used tokens ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: erc erc-6093: custom errors for commonly-used tokens lists custom errors for common token implementations authors ernesto garcía (@ernestognw), francisco giordano (@frangio), hadrien croubois (@amxx) created 2022-12-06 last call deadline 2023-08-15 requires eip-20, eip-721, eip-1155 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification erc-20 erc-721 erc-1155 parameter glossary error additions rationale actions and subjects error prefixes domain arguments error grammar rules backwards compatibility reference implementation solidity security considerations copyright abstract this eip defines a standard set of custom errors for commonly-used tokens, which are defined as erc-20, erc-721, and erc-1155 tokens. ethereum applications and wallets have historically relied on revert reason strings to display the cause of transaction errors to users. recent solidity versions offer rich revert reasons with error-specific decoding (sometimes called “custom errors”). this eip defines a standard set of errors designed to give at least the same relevant information as revert reason strings, but in a structured and expected way that clients can implement decoding for. motivation since the introduction of solidity custom errors in v0.8.4, these have provided a way to show failures in a more expressive and gas efficient manner with dynamic arguments, while reducing deployment costs. however, erc-20, erc-721, erc-1155 were already finalized when custom errors were released, so no errors are included in their specification. standardized errors allow users to expect more consistent error messages across applications or testing environments, while exposing pertinent arguments and overall reducing the need of writing expensive revert strings in the deployment bytecode. 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. the following errors were designed according to the criteria described in rationale. this eip defines standard errors that may be used by implementations in certain scenarios but it does not specify whether implementations should revert in those scenarios, which remains up to the implementers unless a revert is mandated by the corresponding eips. the names of the error arguments are defined in the parameter glossary and must be used according to those definitions. erc-20 erc20insufficientbalance(address sender, uint256 balance, uint256 needed) indicates an error related to the current balance of a sender. used in transfers. usage guidelines: balance must be less than needed. erc20invalidsender(address sender) indicates a failure with the token sender. used in transfers. usage guidelines: recommended for disallowed transfers from the zero address. must not be used for approval operations. must not be used for balance or allowance requirements. use erc20insufficientbalance or erc20insufficientallowance instead. erc20invalidreceiver(address receiver) indicates a failure with the token receiver. used in transfers. usage guidelines: recommended for disallowed transfers to the zero address. recommended for disallowed transfers to non-compatible addresses (eg. contract addresses). must not be used for approval operations. erc20insufficientallowance(address spender, uint256 allowance, uint256 needed) indicates a failure with the spender’s allowance. used in transfers. usage guidelines: allowance must be less than needed. erc20invalidapprover(address approver) indicates a failure with the approver of a token to be approved. used in approvals. usage guidelines: recommended for disallowed approvals from the zero address. must not be used for transfer operations. erc20invalidspender(address spender) indicates a failure with the spender to be approved. used in approvals. usage guidelines: recommended for disallowed approvals to the zero address. recommended for disallowed approvals to the owner itself. must not be used for transfer operations. use erc20insufficientallowance instead. erc-721 erc721invalidowner(address owner) indicates that an address can’t be an owner. used in balance queries. usage guidelines: recommended for addresses whose ownership is disallowed (eg. erc-721 explicitly disallows address(0) to be an owner). must not be used for transfers. use erc721incorrectowner instead. erc721nonexistenttoken(uint256 tokenid) indicates a tokenid whose owner is the zero address. usage guidelines: the tokenid must be a non-minted or burned token. erc721incorrectowner(address sender, uint256 tokenid, address owner) indicates an error related to the ownership over a particular token. used in transfers. usage guidelines: sender must not be owner. must not be used for approval operations. erc721invalidsender(address sender) indicates a failure with the token sender. used in transfers. usage guidelines: recommended for disallowed transfers from the zero address. must not be used for approval operations. must not be used for ownership or approval requirements. use erc721incorrectowner or erc721insufficientapproval instead. erc721invalidreceiver(address receiver) indicates a failure with the token receiver. used in transfers. usage guidelines: recommended for disallowed transfers to the zero address. recommended for disallowed transfers to non-erc721tokenreceiver contracts or those that reject a transfer. (eg. returning an invalid response in onerc721received). must not be used for approval operations. erc721insufficientapproval(address operator, uint256 tokenid) indicates a failure with the operator’s approval. used in transfers. usage guidelines: isapprovedforall(owner, operator) must be false for the tokenid’s owner and operator. getapproved(tokenid) must not be operator. erc721invalidapprover(address approver) indicates a failure with the owner of a token to be approved. used in approvals. usage guidelines: recommended for disallowed approvals from the zero address. must not be used for transfer operations. erc721invalidoperator(address operator) indicates a failure with the operator to be approved. used in approvals. usage guidelines: recommended for disallowed approvals to the zero address. the operator must not be the owner of the approved token. must not be used for transfer operations. use erc721insufficientapproval instead. erc-1155 erc1155insufficientbalance(address sender, uint256 balance, uint256 needed, uint256 tokenid) indicates an error related to the current balance of a sender. used in transfers. usage guidelines: balance must be less than needed for a tokenid. erc1155invalidsender(address sender) indicates a failure with the token sender. used in transfers. usage guidelines: recommended for disallowed transfers from the zero address. must not be used for approval operations. must not be used for balance or allowance requirements. use erc1155insufficientbalance or erc1155missingapprovalforall instead. erc1155invalidreceiver(address receiver) indicates a failure with the token receiver. used in transfers. usage guidelines: recommended for disallowed transfers to the zero address. recommended for disallowed transfers to non-erc1155tokenreceiver contracts or those that reject a transfer. (eg. returning an invalid response in onerc1155received). must not be used for approval operations. erc1155missingapprovalforall(address operator, address owner) indicates a failure with the operator’s approval in a transfer. used in transfers. usage guidelines: isapprovedforall(owner, operator) must be false for the tokenid’s owner and operator. erc1155invalidapprover(address approver) indicates a failure with the approver of a token to be approved. used in approvals. usage guidelines: recommended for disallowed approvals from the zero address. must not be used for transfer operations. erc1155invalidoperator(address operator) indicates a failure with the operator to be approved. used in approvals. usage guidelines: recommended for disallowed approvals to the zero address. must be used for disallowed approvals to the owner itself. must not be used for transfer operations. use erc1155insufficientapproval instead. erc1155invalidarraylength(uint256 idslength, uint256 valueslength) indicates an array length mismatch between ids and values in a safebatchtransferfrom operation. used in batch transfers. usage guidelines: idslength must not be valueslength. parameter glossary name description sender address whose tokens are being transferred. balance current balance for the interacting account. needed minimum amount required to perform an action. receiver address to which tokens are being transferred. spender address that may be allowed to operate on tokens without being their owner. allowance amount of tokens a spender is allowed to operate with. approver address initiating an approval operation. tokenid identifier number of a token. owner address of the current owner of a token. operator same as spender. *length array length for the prefixed parameter. error additions any addition to this eip or implementation-specific errors (such as extensions) should follow the guidelines presented in the rationale section to keep consistency. rationale the chosen objectives for a standard for token errors are to provide context about the error, and to make moderate use of meaningful arguments (to maintain the code size benefits with respect to strings). considering this, the error names are designed following a basic grammatical structure based on the standard actions that can be performed on each token and the subjects involved. actions and subjects an error is defined based on the following actions that can be performed on a token and its involved subjects: transfer: an operation in which a sender moves to a receiver any number of tokens (fungible balance and/or non-fungible token ids). approval: an operation in which an approver grants any form of approval to an operator. these attempt to exhaustively represent what can go wrong in a token operation. therefore, the errors can be constructed by specifying which subject failed during an action execution, and prefixing with an error prefix. note that the action is never seen as the subject of an error. if a subject is called different on a particular token standard, the error should be consistent with the standard’s naming convention. error prefixes an error prefix is added to a subject to derive a concrete error condition. developers can think about an error prefix as the why an error happened. a prefix can be invalid for general incorrectness, or more specific like insufficient for amounts. domain each error’s arguments may vary depending on the token domain. if there are errors with the same name and different arguments, the solidity compiler currently fails with a declarationerror. an example of this is: insufficientapproval(address spender, uint256 allowance, uint256 needed); insufficientapproval(address operator, uint256 tokenid); for that reason, a domain prefix is proposed to avoid declaration clashing, which is the name of the erc and its corresponding number appended at the beginning. example: erc20insufficientapproval(address spender, uint256 allowance, uint256 needed); erc721insufficientapproval(address operator, uint256 tokenid); arguments the selection of arguments depends on the subject involved, and it should follow the order presented below: who is involved with the error (eg. address sender) what failed (eg. uint256 allowance) why it failed, expressed in additional arguments (eg. uint256 needed) a particular argument may fall into overlapping categories (eg. who may also be what), so not all of these will be present but the order shouldn’t be broken. some tokens may need a tokenid. this is suggested to include at the end as additional information instead of as a subject. error grammar rules given the above, we can summarize the construction of error names with a grammar that errors will follow: (); where: domain: erc20, erc721 or erc1155. although other token standards may be suggested if not considered in this eip. errorprefix: invalid, insufficient, or another if it’s more appropriate. subject: sender, receiver, balance, approver, operator, approval or another if it’s more appropriate, and must make adjustments based on the domain’s naming convention. arguments: follow the who, what and why order. backwards compatibility tokens already deployed rely mostly on revert strings and make use of require instead of custom errors. even most of the newly deployed tokens since solidity’s v0.8.4 release inherit from implementations using revert strings. this eip can not be enforced on non-upgradeable already deployed tokens, however, these tokens generally use similar conventions with small variations such as: including/removing the domain. using different error prefixes. including similar subjects. changing the grammar order. upgradeable contracts may be upgraded to implement this eip. implementers and dapp developers that implement special support for tokens that are compliant with this eip, should tolerate different errors emitted by non-compliant contracts, as well as classic revert strings. reference implementation solidity pragma solidity ^0.8.4; /// @title standard erc20 errors /// @dev see https://eips.ethereum.org/eips/eip-20 /// https://eips.ethereum.org/eips/eip-6093 interface erc20errors { error erc20insufficientbalance(address sender, uint256 balance, uint256 needed); error erc20invalidsender(address sender); error erc20invalidreceiver(address receiver); error erc20insufficientallowance(address spender, uint256 allowance, uint256 needed); error erc20invalidapprover(address approver); error erc20invalidspender(address spender); } /// @title standard erc721 errors /// @dev see https://eips.ethereum.org/eips/eip-721 /// https://eips.ethereum.org/eips/eip-6093 interface erc721errors { error erc721invalidowner(address owner); error erc721nonexistenttoken(uint256 tokenid); error erc721incorrectowner(address sender, uint256 tokenid, address owner); error erc721invalidsender(address sender); error erc721invalidreceiver(address receiver); error erc721insufficientapproval(address operator, uint256 tokenid); error erc721invalidapprover(address approver); error erc721invalidoperator(address operator); } /// @title standard erc1155 errors /// @dev see https://eips.ethereum.org/eips/eip-1155 /// https://eips.ethereum.org/eips/eip-6093 interface erc1155errors { error erc1155insufficientbalance(address sender, uint256 balance, uint256 needed, uint256 tokenid); error erc1155invalidsender(address sender); error erc1155invalidreceiver(address receiver); error erc1155missingapprovalforall(address operator, address owner) error erc1155invalidapprover(address approver); error erc1155invalidoperator(address operator); error erc1155invalidarraylength(uint256 idslength, uint256 valueslength); } security considerations there are no known signature hash collisions for the specified errors. tokens upgraded to implement this eip may break assumptions in other systems relying on revert strings. offchain applications should be cautious when dealing with untrusted contracts that may revert using these custom errors. for instance, if a user interface prompts actions based on error decoding, malicious contracts could exploit this to encourage untrusted and potentially harmful operations. copyright copyright and related rights waived via cc0. citation please cite this document as: ernesto garcía (@ernestognw), francisco giordano (@frangio), hadrien croubois (@amxx), "erc-6093: custom errors for commonly-used tokens [draft]," ethereum improvement proposals, no. 6093, december 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6093. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3436: expanded clique block choice rule ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-3436: expanded clique block choice rule authors danno ferrin (@shemnon) created 2021-03-25 discussion link https://ethereum-magicians.org/t/eip-3436-expanded-clique-block-choice-rule/5809 requires eip-225 table of contents simple summary abstract motivation specification rationale backwards compatibility security considerations copyright simple summary add a four step block rule to clique that should reduce block production deadlocks abstract the current specification of clique allows for multiple competing blocks from producers but does not provide any strategies to pick blocks aside from the current “highest total difficulty” rule. this eip proposes a four step choice rule of highest total difficulty, shortest chain, most recently in-turn, and lowest hash. this would prevent deadlocks that have occurred in production systems. motivation there has been more than one deadlock in the goerli multi-client clique network. the number of active validators was greater than 1/2 of the available validators so a chain halt should not have occurred. the halt was resolved by an inactive validator coming back on line. the state of the chain was in one of two configurations of 8 validators that can result in a chain halt. three of the four clients observed a choice sequence of lowest total difficulty followed by first observed block. geth added one extra rule of preferring the shortest chain before preferring the first observed block. this fork would have resolved itself with geth’s rule, but there is still a configuration where the chain can halt with a shortest chain rule. specification when a clique validator is arbitrating the canonical status between two different chain head blocks, they should choose the canonical block with the following ordered priorities. choose the block with the most total difficulty. then choose the block with the lowest block number. then choose the block whose validator had the least recent in-turn block assignment. then choose the block with the lowest hash. when resolving rule 3 clients should use the following formula, where validator_index is the integer index of the validator that signed the block when sorted as per epoch checkpointing, header_number is the number of the header, and validator_count is the count of the current validators. clients should choose the block with the largest value. note that an in-turn block is considered to be the most recent in-turn block. (header_number validator_index) % validator_count when resolving rule 4 the hash should be converted into an unsigned 256 bit integer. rationale two scenarios of a halted chain are known based on the current total difficulty then first observed rule. one of the scenarios is also resistant to the shortest chain rule. for the first scenario where chains of different lengths can halt consider a block with 8 validators, whose addresses sort to the same order as their designation in this example. a fully in-order chain exists and validator number 8 has just produced an in-turn block and then validators 5, 7 and 8 go offline, leaving validators 1 to 6 to produce blocks. two forks form, one with an in-order block from validator 1 and then an out of order block from validator 3. the second fork forms from validators 2, 4, and 6 in order. both have a net total difficulty of 3 more than the common ancestor. so in this case if both forks become aware of the other fork then both are considered equally viable and neither set of validators should switch to the newly observed fork. in this case, adding a shortest chain rule would break the deadlock as the even numbered validators would adopt the shorter chain. for the second scenario with the same validator set and in-order chain with validator 7 having just produced an in order block, then validators 7 and 8 go offline. two forks form, 1,3,5 on one side and 2,4,6 on the other. both forks become aware of the other fork after producing their third block. in this case both forks have equal total difficulty and equal length. so geth’s rule would not break the tie and only the arrival of one of the missing validators fix the chain. in a worst case scenario the odd and even chains would produce a block for 7 and 8 respectively, and chain halt would result with no validators that have not chosen a fork. only a manual rollback would fix this. one consideration when formulating the rules is that the block choice should be chosen so that it would encourage the maximum amount of in-order blocks. selecting a chain based on shortest chain implicitly prefers the chain with more in-order blocks. when selecting between competing out of order chains the validator who is closest to producing an in-order block in the future should have their chain declined so that they are available to produce an in-order block sooner. at least one client has been observed producing multiple blocks at the same height with the same difficulty, so a final catch-all standard of lowest block hash should break any remaining ties. backwards compatibility the current block choice rules are a mix of most total difficulty and most total difficulty plus shortest chain. as long as the majority of the active validators implement the block choice rules then a client who only implements the existing difficulty based rule will eventually align with the chain preferred by these rules. if less than a majority implement these rules then deadlocks can still occur, and depend on the first observation of problematic blocks, which is no worse than the current situation. if clients only partially implement the rule as long as every higher ranked rule is also implemented then the situation will be no worse than today. security considerations malicious and motivated attackers who are participating in the network can force the chain to halt with well crafted block production. with a fully deterministic choice rule the opportunity to halt is diminished. attackers still have the same opportunities to flood the network with multiple blocks at the same height. a deterministic rule based on the lowest hash reduces the impact of such a flooding attack. a malicious validator could exploit this deterministic rule to produce a replacement block. such an attack exists in current implementations but a deterministic hash rule makes such replacements more likely. however the impact of such an attack seems low to trivial at this time. copyright copyright and related rights waived via cc0. citation please cite this document as: danno ferrin (@shemnon), "eip-3436: expanded clique block choice rule [draft]," ethereum improvement proposals, no. 3436, march 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3436. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5000: muldiv instruction ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-5000: muldiv instruction introduce a new instruction to perform x * y / z in 512-bit precision authors harikrishnan mulackal (@hrkrshnn), alex beregszaszi (@axic), paweł bylica (@chfast) created 2022-03-14 discussion link https://ethereum-magicians.org/t/muldiv-instruction/9930 table of contents abstract motivation specification rationale the special 0 case argument ordering backwards compatibility test cases security considerations copyright abstract introduce a new instruction, muldiv(x, y, z), to perform ((x * y) / z) % 2**256 in 512-bit precision. z = 0 is a special case for (x * y) % 2**256. motivation fixed point operations in high level languages are very commonly used on ethereum, especially in the domain of financial applications. while fixed point addition and subtraction can be done with merely add and sub respectively, being able to efficiently do fixedpoint multiplication and division is a very sought after feature. a commonly used workaround relies on a mulmod-based, rather complex implementation (taking around 50 instructions, excluding stack manipulation). this instruction reduces that to a single opcode. a secondary use case is likely in cryptographic applications, where the muldiv instruction allows full precision 256x256->512 multiplication. mul(x y) (or muldiv(x, y, 1)) computes the lower order 256 bits and muldiv(x, y, 0) computes the higher order 256 bits. finally we aimed to provide an instruction which can be efficiently used both in checked and unchecked arithmetic use cases. by checked we mean to abort on conditions including division-by-zero and wrapping behaviour. specification a new instruction is introduced: muldiv (0x1e). pops 3 values from the stack, first x, then y and z. if z == 0, r = (uint512(x) * y) / 2**256. otherwise r = (uint512(x) * y / z) % 2**256, where the intermediate calculation is performed with 512-bit precision. pushes r on the stack. # operations `*` and `//` are done in 512 bit precision def muldiv(x, y, z): if z == 0: return (x * y) // (2**256) else: return ((x * y) // z) % (2**256) the cost of the instruction is 8 gas (aka mid), the same as for addmod and mulmod. rationale the special 0 case all the arithmetic instructions in evm handle division or modulo 0 specially: the instructions return 0. we have decided to break consistency in order to provide a flexible opcode, which can be used to detect wrapping behaviour. alternate options include: returning a flag for wrapping returning two stack items, higher and lower order bits compute the higher order 256 bits in evm: /// returns `hi` such that `x × y = hi × 2**256 + mul(x, y)` function hob(uint x, uint y) returns (uint hi) { uint uint_max = type(uint).max; assembly { let lo := mul(x, y) let mm := mulmod(x, y, uint_max) hi := sub(sub(mm, lo), lt(mm, lo)) } } while this feature is clever and useful, callers must be aware that unlike other evm instructions, passing 0 will have a vastly different behaviour. argument ordering the order of arguments matches addmod and mulmod. backwards compatibility this is a new instruction not present prior. test cases push 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff push 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff push 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff muldiv --0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff push 0x0000000000000000000000000000000000000000000000000000000000000000 push 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff push 0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff muldiv --0xfffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe push 0x0000000000000000000000000000000000000000000000000de0b6b3a7640000 push 0x000000000000000000000000000000000000000000000000016345785d8a0000 push 0x00000000000000000000000000000000000000000000d3c21bcecceda1000000 muldiv --0x00000000000000000000000000000000000000000000152d02c7e14af6800000 security considerations tba copyright copyright and related rights waived via cc0. citation please cite this document as: harikrishnan mulackal (@hrkrshnn), alex beregszaszi (@axic), paweł bylica (@chfast), "eip-5000: muldiv instruction [draft]," ethereum improvement proposals, no. 5000, march 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5000. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-4399: supplant difficulty opcode with prevrandao ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-4399: supplant difficulty opcode with prevrandao expose beacon chain randomness in the evm by supplanting difficulty opcode semantics authors mikhail kalinin (@mkalinin), danny ryan (@djrtwo) created 2021-10-30 requires eip-3675 table of contents abstract motivation specification definitions block structure evm renaming rationale including randao output in the block header using mixhash field instead of difficulty reusing existing field instead of appending a new one reusing the difficulty opcode instead of introducing a new one renaming the field and the opcode using transition_block rather than a block or slot number using 2**64 threshold to determine pos blocks backwards compatibility test cases security considerations biasability predictability tips for application developers copyright abstract this eip supplants the semantics of the return value of existing difficulty (0x44) opcode and renames the opcode to prevrandao (0x44). the return value of the difficulty (0x44) instruction after this change is the output of the randomness beacon provided by the beacon chain. motivation applications may benefit from using the randomness accumulated by the beacon chain. thus, randomness outputs produced by the beacon chain should be accessible in the evm. at the point of transition_block of the proof-of-stake (pos) upgrade described in eip-3675, the difficulty block field must be 0 thereafter because there is no longer any proof-of-work (pow) seal on the block. this means that the difficulty (0x44) instruction no longer has it’s previous semantic meaning, nor a clear “correct” value to return. given prior analysis on the usage of difficulty, the value returned by the instruction mixed with other values is a common pattern used by smart contracts to obtain randomness. the instruction with the same number as the difficulty opcode returning outputs of the beacon chain randao implementation makes the upgrade to pos backwards compatible for existing smart contracts obtaining randomness from the difficulty instruction. additionally, changes proposed by this eip allow for smart contracts to determine whether the upgrade to the pos has already happened. this can be done by analyzing the return value of the difficulty instruction. a value greater than 2**64 indicates that the transaction is being executed in the pos block. decompilers and other similar tooling may also use this trick to discern the new semantics of the instruction if data of the block including the transaction in question is available. specification definitions transition_block the definition of this block can be found in the definitions section of eip-3675. block structure beginning with transition_block, client software must set the value of the mixhash, i.e. the field with the number 13 (0-indexed) in a block header, to the latest randao mix of the post beacon state of the previous block. evm beginning with transition_block, the difficulty (0x44) instruction must return the value of the mixhash field. note: the gas cost of the difficulty (0x44) opcode remains unchanged. renaming the mixhash field should further be renamed to prevrandao. the difficulty (0x44) opcode should further be renamed to prevrandao (0x44). rationale including randao output in the block header including a randao output in the block header provides a straightforward method of accessing it from inside of the evm as block header data is already available in the evm context. additionally, this ensures that the execution layer can be fully executed with the block alone rather than requiring extra inputs from the pos consensus layer. mixing the randomness into a block header may contribute to uniqueness of the block hash in the case when values of other fields of the block header match the corresponding values of the header of another block. using mixhash field instead of difficulty the mixhash header field is used instead of difficulty to avoid a class of hidden forkchoice bugs after the pos upgrade. client software implementing pre-eip-3675 logic heavily depends on the difficulty value as total difficulty computation is the basis of the pow fork choice rule. setting the difficulty field to 0 at the pos upgrade aims to reduce the surface of bugs related to the total difficulty value growing after the upgrade. additionally, any latent total difficulty computation after the pos upgrade would become overflow prone if the randomness output supplanted the value of the difficulty field. reusing existing field instead of appending a new one the mixhash field is deprecated at the pos upgrade and set to zero bytes array thereafter. reusing an existing field as a place for the randomness output saves 32 bytes per block and effectively removes the deprecation of one of the fields induced by the upgrade. reusing the difficulty opcode instead of introducing a new one see the motivation. renaming the field and the opcode the renaming should be done to make the field and the opcode names semantically sound. using transition_block rather than a block or slot number by utilizing transition_block to trigger the change in logic defined in this eip rather than a block or slot number, this eip is tightly coupled to the pos upgrade defined by eip-3675. by tightly coupling to the pos upgrade, we ensure that there is no discontinuity for the usecase of this opcode for randomness – the primary motivation for re-using difficulty rather than creating a new opcode. using 2**64 threshold to determine pos blocks the probability of randao value to fall into the range between 0 and 2**64 and, thus, to be mixed with pow difficulty values, is drastically low. though, proposed threshold might seem to have insufficient distance from difficulty values on ethereum mainnet (they are currently around 2**54), it requires a thousand times increase of the hashrate to make this threshold insecure. such an increase is considered impossible to occur before the upcoming consensus upgrade. backwards compatibility this eip introduces backward incompatible changes to the execution and validation of evm state transitions. as written, this eip utilizes transition_block and is thus tightly coupled with the pos upgrade introduced in eip-3675. if this eip is to be adopted, it must be scheduled at the same time as eip-3675. additionally, the changes proposed might be backward incompatible for the following categories of applications: applications that use the value returned by the difficulty opcode as the pow difficulty parameter applications with logic that depends on the difficulty opcode returning a relatively small number with respect to the full 256-bit size of the field. the first category is already affected by switching the consensus mechanism to pos and no additional breaking changes are introduced by this specification. the second category is comprised of applications that use the return value of the difficulty opcode in operations that might cause either overflow or underflow errors. while it is theoretically possible to author an application where a change in the range of possible values this opcode may return could lead to a security vulnerability, the chances of that are negligible. test cases in one of ancestors of transition_block deploy a contract that stores return value of difficulty (0x44) to the state check that value returned by difficulty (0x44) in transaction executed within the parent of transition_block equals difficulty field value check that value returned by prevrandao (0x44) in transaction executed within transition_block equals prevrandao field value security considerations the prevrandao (0x44) opcode in pos ethereum (based on the beacon chain randao implementation) is a source of randomness with different properties to the randomness supplied by blockhash (0x40) or difficulty (0x44) opcodes in the pow network. biasability the beacon chain randao implementation gives every block proposer 1 bit of influence power per slot. proposer may deliberately refuse to propose a block on the opportunity cost of proposer and transaction fees to prevent beacon chain randomness (a randao mix) from being updated in a particular slot. an effect of proposer’s influence power is limited in time and lasts until the first honest randao reveal is made afterwards. this limitation does also exist in the case when proposers of n consecutive slots are colluding to get n bits of influence power. simply speaking, one honest block proposal is enough to unbias the randao even if it was biased during several slots in a row. additionally, semantics of the prevrandao (0x44) instruction gives proposers another way to gain 1 bit of influence power on applications. biased proposer may censor a rolling the dice transaction to force it to be included into the next block, thus, force it to use a randao mix that the proposer knows in advance. the opportunity cost in this case would be negligible. predictability obviously, historical randomness provided by any decentralized oracle is 100% predictable. on the contrary, the randomness that is revealed in the future is predictable up to a limited extent. a list of inputs influencing future randomness on the beacon chain consists of but is not limited to the following items: accumulated randomness. a randao mix produced by the beacon chain in the last slot of epoch n is the main input to the function defining block proposers in each slot of epoch n + min_seed_lookahead + 1, i.e. it is the main factor defining future randao revealers. number of active validators. a number of active validators throughout an epoch is another input to the block proposer function. effective balance. all else being equal, the lower the effective balance of a validator the lower the chance this validator has to be designated as a proposer in a slot. accidentally missed proposals. network conditions and other factors that are resulting in accidentally missed proposals is a source of highly qualitative entropy that impacts randao mixes. usual rate of missed proposals on the mainnet is about 1%. these inputs may be predictable and malleable on a short range of slots but the longer the attempted lookahead the more entropy is accumulated by the beacon chain. tips for application developers the following tips attempt to reduce predictability and biasability of randomness outputs returned by prevrandao (0x44): make your applications rely on the future randomness with a reasonably high lookahead. for example, an application stops accepting bids at the end of epoch k and uses a randao mix produced in slot k + n + ε to roll the dice, where n is a lookahead in epochs and ε is a few slots into epoch n + 1. at least four epochs of lookahead results in the following outcome: a proposer set of epoch n + 1 isn’t known at the end of epoch k breaking a direct link between bidders and dice rollers a number of active validators is updated at the end of each epoch affecting a set of proposers of next epochs, thus, impacting a randao mix used by the application to roll the dice due to mainnet statistics, there is about a 100% chance for the network to accidentally miss a proposal during this period of time which reduces predictability of a randao mix used to roll the dice. setting ε to a small number, e.g. 2 or 4 slots, gives a third party a little time to gain influence power on the future randomness that is being used to roll the dice. this amount of time is defined by min_seed_lookahead parameter and is about 6 minutes on the mainnet. a reasonably high distance between bidding and rolling the dice attempts to leave low chance for bidders controlling a subset of validators to directly exploit their influence power. ultimately, this chance depends on the type of the game and on a number of controlled validators. for instance, a chance of a single validator to affect a one-time game is negligible, and becomes bigger for multiple validators in a repeated game scenario. copyright copyright and related rights waived via cc0. citation please cite this document as: mikhail kalinin (@mkalinin), danny ryan (@djrtwo), "eip-4399: supplant difficulty opcode with prevrandao," ethereum improvement proposals, no. 4399, october 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4399. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1010: uniformity between 0xab5801a7d398351b8be11c439e05c5b3259aec9b and 0x15e55ef43efa8348ddaeaa455f16c43b64917e3c ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1010: uniformity between 0xab5801a7d398351b8be11c439e05c5b3259aec9b and 0x15e55ef43efa8348ddaeaa455f16c43b64917e3c authors anderson wesley (@andywesley) created 2018-04-18 discussion link https://github.com/andywesley/eips/issues/1 table of contents simple summary abstract motivation specification rationale backwards compatibility copyright simple summary this document proposes to improve the uniformity of ether distribution between wallet address 0xab5801a7d398351b8be11c439e05c5b3259aec9b and wallet address 0x15e55ef43efa8348ddaeaa455f16c43b64917e3c which are currently experiencing a significant non-uniformity. abstract as of the date of this eip, the difference in balance between address 0xab5801a7d398351b8be11c439e05c5b3259aec9b and address 0x15e55ef43efa8348ddaeaa455f16c43b64917e3c is far from equitable or uniform, with the former having more than 365,000 ether more than the latter. the distribution of ether between these two addresses must be improved in order to protect the ethereum economy from centralized control. this will be accomplished by transferring 100,000 ether from the former address to the latter. this is a properly motivated improvement in keeping with the core ethereum philosophy of decentralization. motivation this proposal is necessary because the ethereum protocol does not allow the owner of an address which does not own an equitable amount of ether to claim their share of ether from an address which owns a dangerously centralized quantity. rather than proposing an overly complicated generic mechanism for any user to claim ether to which they believe they are equitably entitled, this proposal will take the simple route of a one-time transfer of 100,000 ether from 0xab5801a7d398351b8be11c439e05c5b3259aec9b to 0x15e55ef43efa8348ddaeaa455f16c43b64917e3c. this avoids duplicating the effort of other proposals and provides a net improvement to the ethereum project and community. specification the balance of 0xab5801a7d398351b8be11c439e05c5b3259aec9b will be decreased by 100,000 ether. the balance of 0x15e55ef43efa8348ddaeaa455f16c43b64917e3c will be increased by 100,000 ether. no net change in the amount of extant ether will occur unless at the time of implementation the former address does not contain sufficient ether for such a deduction. rationale the value 100,000 was chosen after careful technically sound analysis of various economic theories developed over the past century. in spite of the fact that it is a convenient round number, it is actually the exact output of a complex statistical process iterated to determine the optimal distribution of ether between these addresses. backwards compatibility clients that fail to implement this change will not be aware of the correct balances for these addresses. this will create a hard fork. the implementation of this change consistently among all clients as intended by the proposal process will be sufficient to ensure that backwards compatibility is not a concern. copyright copyright and related rights waived via cc0. citation please cite this document as: anderson wesley (@andywesley), "eip-1010: uniformity between 0xab5801a7d398351b8be11c439e05c5b3259aec9b and 0x15e55ef43efa8348ddaeaa455f16c43b64917e3c [draft]," ethereum improvement proposals, no. 1010, april 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1010. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6206: eof jumpf and non-returning functions ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: core eip-6206: eof jumpf and non-returning functions introduces instruction for chaining function calls. authors andrei maiboroda (@gumb0), alex beregszaszi (@axic), paweł bylica (@chfast), matt garnett (@lightclient) created 2022-12-21 discussion link https://ethereum-magicians.org/t/eip-4750-eof-functions/8195 requires eip-4750, eip-5450 table of contents abstract motivation specification type section changes execution semantics code validation rationale allowing jumpf to section with less outputs backwards compatibility security considerations copyright abstract this eip allows for tail call optimizations in eof functions (eip-4750) by introducing a new instruction jumpf, which jumps to a code section without adding a new return stack frame. additionally the format of the type sections is extended to allow declaring sections as non-returning, with simplified stack validation for jumpf to such section. motivation it is common for functions to make a call at the end of the routine only to then return. jumpf optimizes this behavior by changing code sections without needing to update the return stack. knowing at validation time that a function will never return control allows for jumpf to such function to be treated similar to terminating instructions, where extra items may be left on the operand stack at execution termination. this provides opportunities for compilers to generate more optimal code, both in code size and in spent gas. it is particularly benefitial for small error handling helpers, that end execution with revert: they are commonly reused in multiple branches and extracting them into a helper function is efficient, when there is no need to pop extra stack items before jumpf to such helper. specification type section changes we define non-returning section as the one that can not return control (via retf instruction) to the caller section. type section outputs field contains a special value 0x80 when corresponding code section is non-returning. see non-returning status validation below for validation details. the first code section must have 0 inputs and be non-returning. execution semantics a new instruction, jumpf (0xe5), is introduced. jumpf has one immediate argument, target_section_index, encoded as a 16-bit unsigned big-endian value. if the operand stack size exceeds 1024 type[target_section_index].max_stack_height (i.e. if the called function may exceed the global stack height limit), execution results in an exceptional halt. this guarantees that the target function does not exceed global stack height limit. jumpf sets current_section_index to target_section_index and pc to 0, but does not change the return stack. execution continues in the target section. jumpf costs 5 gas. jumpf neither pops nor pushes anything to the operand stack. code validation let the definition of type[i] be inherited from eip-4750 and define stack_height to be the height of the stack at a certain instruction during the instruction flow traversal if the operand stack at the start of the function were equal to type[i].inputs. the immediate argument of jumpf must be less than the total number of code sections. for each jumpf instruction: either type[current_section_index].outputs must be greater or equal type[target_section_index].outputs, or type[target_section_index].outputs must be 0x80 the stack height validation at jumpf depends on whether the target section is non-returning: jumpf into returning section (type[target_section_index].outputs does not equal 0x80): stack height must be equal to type[current_section_index].outputs + type[target_section_index].inputs type[target_section_index].outputs. this means that target section can output less stack elements than the original code section called by the top element on the return stack, if the current code section leaves the delta type[current_section_index].outputs type[target_section_index].outputs element(s) on the stack. jumpf into non-returning section (type[target_section_index].outputs equals 0x80): stack height must be greater or equal than type[target_section_index].inputs. jumpf is considered terminating instruction, i.e. does not have successor instructions in code validation and may be final instruction in the section. the code validation defined in eip-4200 also fails if any rjump* offset points to one of the two bytes directly following a jumpf instruction. callf instruction validation is extended to include the rule: code section is invalid in case an immediate argument target_section_index of any callf targets a non-returning section, i.e. type[target_section_index equals 0x80. non-returning status validation section type must be non-returning in case the section contains no retf instructions and no jumpf instructions targeting returning sections (target section’s status is checked via its output value in type section.) note: this implies that section containing only jumpfs into non-returning sections is non-returning itself. rationale allowing jumpf to section with less outputs as long as jumpf prepares the delta type[current_section_index].outputs type[target_section_index].outputs stack elements before changing code sections, it is possible to jump to a section with less outputs than was originally entered via callf. this will reduce duplicated code as it will allow compilers more flexibility during code generation such that certain helpers can be used generically by functions, regardless of their output values. backwards compatibility this change is backward compatible as eof does not allow undefined instructions to be used or deployed, meaning no contracts will be affected. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: andrei maiboroda (@gumb0), alex beregszaszi (@axic), paweł bylica (@chfast), matt garnett (@lightclient), "eip-6206: eof jumpf and non-returning functions [draft]," ethereum improvement proposals, no. 6206, december 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6206. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-7587: reserve precompile address range for rips ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft informational eip-7587: reserve precompile address range for rips reserve precompile address range for use by the rip process authors carl beekhuizen (@carlbeek), ansgar dietrichs (@adietrichs), danny ryan (@djrtwo), tim beiko (@timbeiko) created 2023-12-21 discussion link https://ethereum-magicians.org/t/eip-75xx-reserve-precompile-address-range-for-rips-l2s/17828 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip reserves precompile ranges to ensure there are no conflicts with those used by the rollup improvement proposal (rip) process. motivation as l2s begin to deploy rips, it is necessary to reserve an address range for use by the rip process so as to ensure there are no conflicts between precompile addresses used by rips and eips. specification the address range between 0x0000000000000000000000000000000000000100 and 0x00000000000000000000000000000000000001ff is reserved for use by the rip process. rationale by reserving an address range for rips, it allows the rip process to maintain it’s own registry of precompiles that are not (necessarily) deployed on l1 mainnet, the eip process is freed from having to maintain a registry of rip precompiles while still having 255 addresses for it’s own use. backwards compatibility no backward compatibility issues found. security considerations nil. copyright copyright and related rights waived via cc0. citation please cite this document as: carl beekhuizen (@carlbeek), ansgar dietrichs (@adietrichs), danny ryan (@djrtwo), tim beiko (@timbeiko), "eip-7587: reserve precompile address range for rips [draft]," ethereum improvement proposals, no. 7587, december 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7587. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-8: devp2p forward compatibility requirements for homestead ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: networking eip-8: devp2p forward compatibility requirements for homestead authors felix lange created 2015-12-18 table of contents abstract specification motivation rationale backwards compatibility implementation test vectors copyright abstract this eip introduces new forward-compatibility requirements for implementations of the devp2p wire protocol, the rlpx discovery protocol and the rlpx tcp transport protocol. clients which implement eip-8 behave according to postel’s law: be conservative in what you do, be liberal in what you accept from others. specification implementations of the devp2p wire protocol should ignore the version number of hello packets. when sending the hello packet, the version element should be set to the highest devp2p version supported. implementations should also ignore any additional list elements at the end of the hello packet. similarly, implementations of the rlpx discovery protocol should not validate the version number of the ping packet, ignore any additional list elements in any packet, and ignore any data after the first rlp value in any packet. discovery packets with unknown packet type should be discarded silently. the maximum size of any discovery packet is still 1280 bytes. finally, implementations of the rlpx tcp transport protocol should accept a new encoding for the encrypted key establishment handshake packets. if an eip-8 style rlpx auth-packet is received, the corresponding ack-packet should be sent using the rules below. decoding the rlp data in auth-body and ack-body should ignore mismatches of auth-vsn and ack-vsn, any additional list elements and any trailing data after the list. during the transitioning period (i.e. until the old format has been retired), implementations should pad auth-body with at least 100 bytes of junk data. adding a random amount in range [100, 300] is recommended to vary the size of the packet. auth-vsn = 4 auth-size = size of enc-auth-body, encoded as a big-endian 16-bit integer auth-body = rlp.list(sig, initiator-pubk, initiator-nonce, auth-vsn) enc-auth-body = ecies.encrypt(recipient-pubk, auth-body, auth-size) auth-packet = auth-size || enc-auth-body ack-vsn = 4 ack-size = size of enc-ack-body, encoded as a big-endian 16-bit integer ack-body = rlp.list(recipient-ephemeral-pubk, recipient-nonce, ack-vsn) enc-ack-body = ecies.encrypt(initiator-pubk, ack-body, ack-size) ack-packet = ack-size || enc-ack-body where x || y denotes concatenation of x and y. x[:n] denotes an n-byte prefix of x. rlp.list(x, y, z, ...) denotes recursive encoding of [x, y, z, ...] as an rlp list. sha3(message) is the keccak256 hash function as used by ethereum. ecies.encrypt(pubkey, message, authdata) is the asymmetric authenticated encryption function as used by rlpx. authdata is authenticated data which is not part of the resulting ciphertext, but written to hmac-256 before generating the message tag. motivation changes to the devp2p protocols are hard to deploy because clients running an older version will refuse communication if the version number or structure of the hello (discovery ping, rlpx handshake) packet does not match local expectations. introducing forward-compatibility requirements as part of the homestead consensus upgrade will ensure that all client software in use on the ethereum network can cope with future network protocol upgrades (as long as backwards-compatibility is maintained). rationale the proposed changes address forward compatibility by applying postel’s law (also known as the robustness principle) throughout the protocol stack. the merit and applicability of this approach has been studied repeatedly since its original application in rfc 761. for a recent perspective, see “the robustness principle reconsidered” (eric allman, 2011). changes to the devp2p wire protocol all clients currently contain statements such as the following: # pydevp2p/p2p_protocol.py if data['version'] != proto.version: log.debug('incompatible network protocols', peer=proto.peer, expected=proto.version, received=data['version']) return proto.send_disconnect(reason=reasons.incompatibel_p2p_version) these checks make it impossible to change the version or structure of the hello packet. dropping them enables switching to a newer protocol version: clients implementing a newer version simply send a packet with higher version and possibly additional list elements. if such a packet is received by a node with lower version, it will blindly assume that the remote end is backwards-compatible and respond with the old handshake. if the packet is received by a node with equal version, new features of the protocol can be used. if the packet is received by a node with higher version, it can enable backwards-compatibility logic or drop the connection. changes to the rlpx discovery protocol the relaxation of discovery packet decoding rules largely codifies current practice. most existing implementations do not care about the number of list elements (an exception being go-ethereum) and do not reject nodes with mismatching version. this behaviour is not guaranteed by the spec, though. if adopted, the change makes it possible to deploy protocol changes in a similar manner to the devp2p hello change: simply bump the version and send additional information. older clients will ignore the additional elements and can continue to operate even when the majority of the network has moved on to a newer protocol. changes to the rlpx tcp handshake discussions of the rlpx v5 changes (chunked packets, change to key derivation) have faltered in part because the v4 handshake encoding provides only one in-band way to add a version number: shortening the random portion of the nonce. even if the rlpx v5 handshake proposal were accepted, future upgrades are hard because the handshake packet is a fixed size ecies ciphertext with known layout. i propose the following changes to the handshake packets: adding the length of the ciphertext as a plaintext header. encoding the body of the handshake as rlp. adding a version number to both packets in place of the token flag (unused). removing the hash of the ephemeral public key (it is redundant). these changes make it possible to upgrade the rlpx tcp transport protocol in the same manner as described for the other protocols, i.e. by adding list elements and bumping the version. since this is the first change to the rlpx handshake packet, we can seize the opportunity to remove all currently unused fields. additional data is permitted (and in fact required) after the rlp list because the handshake packet needs to grow in order to be distinguishable from the old format. clients can employ logic such as the following pseudocode to handle both formats simultaneously. packet = read(307, connection) if decrypt(packet) { // process as old format } else { size = unpack_16bit_big_endian(packet) packet += read(size 307 + 2, connection) if !decrypt(packet) { // error } // process as new format } the plain text size prefix is perhaps the most controversial aspect of this document. it has been argued that the prefix aids adversaries that seek to filter and identify rlpx connections on the network level. this is largely a question of how much effort the adversary is willing to expense. if the recommendation to randomise the lengths is followed, pure pattern-based packet recognition is unlikely to succeed. for typical firewall operators, blocking all connections whose first two bytes form an integer in range [300,600] is probably too invasive. port-based blocking would be a more effective measure to filter most rlpx traffic. for an attacker who can afford to correlate many criteria, the size prefix would ease recognition because it adds to the indicator set. however, such an attacker could also be expected to read or participate in rlpx discovery traffic, which would be sufficient to enable blocking of rlpx tcp connections whatever their format is. backwards compatibility this eip is backwards-compatible, all valid version 4 packets are still accepted. implementation go-ethereum libweb3core pydevp2p test vectors devp2p base protocol devp2p hello packet advertising version 22 and containing a few additional list elements: f87137916b6e6574682f76302e39312f706c616e39cdc5836574683dc6846d6f726b1682270fb840 fda1cff674c90c9a197539fe3dfb53086ace64f83ed7c6eabec741f7f381cc803e52ab2cd55d5569 bce4347107a310dfd5f88a010cd2ffd1005ca406f1842877c883666f6f836261720304 rlpx discovery protocol implementations should accept the following encoded discovery packets as valid. the packets are signed using the secp256k1 node key b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291 ping packet with version 4, additional list elements: e9614ccfd9fc3e74360018522d30e1419a143407ffcce748de3e22116b7e8dc92ff74788c0b6663a aa3d67d641936511c8f8d6ad8698b820a7cf9e1be7155e9a241f556658c55428ec0563514365799a 4be2be5a685a80971ddcfa80cb422cdd0101ec04cb847f000001820cfa8215a8d790000000000000 000000000000000000018208ae820d058443b9a3550102 ping packet with version 555, additional list elements and additional random data: 577be4349c4dd26768081f58de4c6f375a7a22f3f7adda654d1428637412c3d7fe917cadc56d4e5e 7ffae1dbe3efffb9849feb71b262de37977e7c7a44e677295680e9e38ab26bee2fcbae207fba3ff3 d74069a50b902a82c9903ed37cc993c50001f83e82022bd79020010db83c4d001500000000abcdef 12820cfa8215a8d79020010db885a308d313198a2e037073488208ae82823a8443b9a355c5010203 040531b9019afde696e582a78fa8d95ea13ce3297d4afb8ba6433e4154caa5ac6431af1b80ba7602 3fa4090c408f6b4bc3701562c031041d4702971d102c9ab7fa5eed4cd6bab8f7af956f7d565ee191 7084a95398b6a21eac920fe3dd1345ec0a7ef39367ee69ddf092cbfe5b93e5e568ebc491983c09c7 6d922dc3 pong packet with additional list elements and additional random data: 09b2428d83348d27cdf7064ad9024f526cebc19e4958f0fdad87c15eb598dd61d08423e0bf66b206 9869e1724125f820d851c136684082774f870e614d95a2855d000f05d1648b2d5945470bc187c2d2 216fbe870f43ed0909009882e176a46b0102f846d79020010db885a308d313198a2e037073488208 ae82823aa0fbc914b16819237dcd8801d7e53f69e9719adecb3cc0e790c57e91ca4461c9548443b9 a355c6010203c2040506a0c969a58f6f9095004c0177a6b47f451530cab38966a25cca5cb58f0555 42124e findnode packet with additional list elements and additional random data: c7c44041b9f7c7e41934417ebac9a8e1a4c6298f74553f2fcfdcae6ed6fe53163eb3d2b52e39fe91 831b8a927bf4fc222c3902202027e5e9eb812195f95d20061ef5cd31d502e47ecb61183f74a504fe 04c51e73df81f25c4d506b26db4517490103f84eb840ca634cae0d49acb401d8a4c6b6fe8c55b70d 115bf400769cc1400f3258cd31387574077f301b421bc84df7266c44e9e6d569fc56be0081290476 7bf5ccd1fc7f8443b9a35582999983999999280dc62cc8255c73471e0a61da0c89acdc0e035e260a dd7fc0c04ad9ebf3919644c91cb247affc82b69bd2ca235c71eab8e49737c937a2c396 neighbours packet with additional list elements and additional random data: c679fc8fe0b8b12f06577f2e802d34f6fa257e6137a995f6f4cbfc9ee50ed3710faf6e66f932c4c8 d81d64343f429651328758b47d3dbc02c4042f0fff6946a50f4a49037a72bb550f3a7872363a83e1 b9ee6469856c24eb4ef80b7535bcf99c0004f9015bf90150f84d846321163782115c82115db84031 55e1427f85f10a5c9a7755877748041af1bcd8d474ec065eb33df57a97babf54bfd2103575fa8291 15d224c523596b401065a97f74010610fce76382c0bf32f84984010203040101b840312c55512422 cf9b8a4097e9a6ad79402e87a15ae909a4bfefa22398f03d20951933beea1e4dfa6f968212385e82 9f04c2d314fc2d4e255e0d3bc08792b069dbf8599020010db83c4d001500000000abcdef12820d05 820d05b84038643200b172dcfef857492156971f0e6aa2c538d8b74010f8e140811d53b98c765dd2 d96126051913f44582e8c199ad7c6d6819e9a56483f637feaac9448aacf8599020010db885a308d3 13198a2e037073488203e78203e8b8408dcab8618c3253b558d459da53bd8fa68935a719aff8b811 197101a4b2b47dd2d47295286fc00cc081bb542d760717d1bdd6bec2c37cd72eca367d6dd3b9df73 8443b9a355010203b525a138aa34383fec3d2719a0 rlpx handshake in these test vectors, node a initiates a connection with node b. the values contained in all packets are given below: static key a: 49a7b37aa6f6645917e7b807e9d1c00d4fa71f18343b0d4122a4d2df64dd6fee static key b: b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291 ephemeral key a: 869d6ecf5211f1cc60418a13b9d870b22959d0c16f02bec714c960dd2298a32d ephemeral key b: e238eb8e04fee6511ab04c6dd3c89ce097b11f25d584863ac2b6d5b35b1847e4 nonce a: 7e968bba13b6c50e2c4cd7f241cc0d64d1ac25c7f5952df231ac6a2bda8ee5d6 nonce b: 559aead08264d5795d3909718cdd05abd49572e84fe55590eef31a88a08fdffd (auth₁) rlpx v4 format (sent from a to b): 048ca79ad18e4b0659fab4853fe5bc58eb83992980f4c9cc147d2aa31532efd29a3d3dc6a3d89eaf 913150cfc777ce0ce4af2758bf4810235f6e6ceccfee1acc6b22c005e9e3a49d6448610a58e98744 ba3ac0399e82692d67c1f58849050b3024e21a52c9d3b01d871ff5f210817912773e610443a9ef14 2e91cdba0bd77b5fdf0769b05671fc35f83d83e4d3b0b000c6b2a1b1bba89e0fc51bf4e460df3105 c444f14be226458940d6061c296350937ffd5e3acaceeaaefd3c6f74be8e23e0f45163cc7ebd7622 0f0128410fd05250273156d548a414444ae2f7dea4dfca2d43c057adb701a715bf59f6fb66b2d1d2 0f2c703f851cbf5ac47396d9ca65b6260bd141ac4d53e2de585a73d1750780db4c9ee4cd4d225173 a4592ee77e2bd94d0be3691f3b406f9bba9b591fc63facc016bfa8 (auth₂) eip-8 format with version 4 and no additional list elements (sent from a to b): 01b304ab7578555167be8154d5cc456f567d5ba302662433674222360f08d5f1534499d3678b513b 0fca474f3a514b18e75683032eb63fccb16c156dc6eb2c0b1593f0d84ac74f6e475f1b8d56116b84 9634a8c458705bf83a626ea0384d4d7341aae591fae42ce6bd5c850bfe0b999a694a49bbbaf3ef6c da61110601d3b4c02ab6c30437257a6e0117792631a4b47c1d52fc0f8f89caadeb7d02770bf999cc 147d2df3b62e1ffb2c9d8c125a3984865356266bca11ce7d3a688663a51d82defaa8aad69da39ab6 d5470e81ec5f2a7a47fb865ff7cca21516f9299a07b1bc63ba56c7a1a892112841ca44b6e0034dee 70c9adabc15d76a54f443593fafdc3b27af8059703f88928e199cb122362a4b35f62386da7caad09 c001edaeb5f8a06d2b26fb6cb93c52a9fca51853b68193916982358fe1e5369e249875bb8d0d0ec3 6f917bc5e1eafd5896d46bd61ff23f1a863a8a8dcd54c7b109b771c8e61ec9c8908c733c0263440e 2aa067241aaa433f0bb053c7b31a838504b148f570c0ad62837129e547678c5190341e4f1693956c 3bf7678318e2d5b5340c9e488eefea198576344afbdf66db5f51204a6961a63ce072c8926c (auth₃) eip-8 format with version 56 and 3 additional list elements (sent from a to b): 01b8044c6c312173685d1edd268aa95e1d495474c6959bcdd10067ba4c9013df9e40ff45f5bfd6f7 2471f93a91b493f8e00abc4b80f682973de715d77ba3a005a242eb859f9a211d93a347fa64b597bf 280a6b88e26299cf263b01b8dfdb712278464fd1c25840b995e84d367d743f66c0e54a586725b7bb f12acca27170ae3283c1073adda4b6d79f27656993aefccf16e0d0409fe07db2dc398a1b7e8ee93b cd181485fd332f381d6a050fba4c7641a5112ac1b0b61168d20f01b479e19adf7fdbfa0905f63352 bfc7e23cf3357657455119d879c78d3cf8c8c06375f3f7d4861aa02a122467e069acaf513025ff19 6641f6d2810ce493f51bee9c966b15c5043505350392b57645385a18c78f14669cc4d960446c1757 1b7c5d725021babbcd786957f3d17089c084907bda22c2b2675b4378b114c601d858802a55345a15 116bc61da4193996187ed70d16730e9ae6b3bb8787ebcaea1871d850997ddc08b4f4ea668fbf3740 7ac044b55be0908ecb94d4ed172ece66fd31bfdadf2b97a8bc690163ee11f5b575a4b44e36e2bfb2 f0fce91676fd64c7773bac6a003f481fddd0bae0a1f31aa27504e2a533af4cef3b623f4791b2cca6 d490 (ack₁) rlpx v4 format (sent from b to a): 049f8abcfa9c0dc65b982e98af921bc0ba6e4243169348a236abe9df5f93aa69d99cadddaa387662 b0ff2c08e9006d5a11a278b1b3331e5aaabf0a32f01281b6f4ede0e09a2d5f585b26513cb794d963 5a57563921c04a9090b4f14ee42be1a5461049af4ea7a7f49bf4c97a352d39c8d02ee4acc416388c 1c66cec761d2bc1c72da6ba143477f049c9d2dde846c252c111b904f630ac98e51609b3b1f58168d dca6505b7196532e5f85b259a20c45e1979491683fee108e9660edbf38f3add489ae73e3dda2c71b d1497113d5c755e942d1 (ack₂) eip-8 format with version 4 and no additional list elements (sent from b to a): 01ea0451958701280a56482929d3b0757da8f7fbe5286784beead59d95089c217c9b917788989470 b0e330cc6e4fb383c0340ed85fab836ec9fb8a49672712aeabbdfd1e837c1ff4cace34311cd7f4de 05d59279e3524ab26ef753a0095637ac88f2b499b9914b5f64e143eae548a1066e14cd2f4bd7f814 c4652f11b254f8a2d0191e2f5546fae6055694aed14d906df79ad3b407d94692694e259191cde171 ad542fc588fa2b7333313d82a9f887332f1dfc36cea03f831cb9a23fea05b33deb999e85489e645f 6aab1872475d488d7bd6c7c120caf28dbfc5d6833888155ed69d34dbdc39c1f299be1057810f34fb e754d021bfca14dc989753d61c413d261934e1a9c67ee060a25eefb54e81a4d14baff922180c395d 3f998d70f46f6b58306f969627ae364497e73fc27f6d17ae45a413d322cb8814276be6ddd13b885b 201b943213656cde498fa0e9ddc8e0b8f8a53824fbd82254f3e2c17e8eaea009c38b4aa0a3f306e8 797db43c25d68e86f262e564086f59a2fc60511c42abfb3057c247a8a8fe4fb3ccbadde17514b7ac 8000cdb6a912778426260c47f38919a91f25f4b5ffb455d6aaaf150f7e5529c100ce62d6d92826a7 1778d809bdf60232ae21ce8a437eca8223f45ac37f6487452ce626f549b3b5fdee26afd2072e4bc7 5833c2464c805246155289f4 (ack₃) eip-8 format with version 57 and 3 additional list elements (sent from b to a): 01f004076e58aae772bb101ab1a8e64e01ee96e64857ce82b1113817c6cdd52c09d26f7b90981cd7 ae835aeac72e1573b8a0225dd56d157a010846d888dac7464baf53f2ad4e3d584531fa203658fab0 3a06c9fd5e35737e417bc28c1cbf5e5dfc666de7090f69c3b29754725f84f75382891c561040ea1d dc0d8f381ed1b9d0d4ad2a0ec021421d847820d6fa0ba66eaf58175f1b235e851c7e2124069fbc20 2888ddb3ac4d56bcbd1b9b7eab59e78f2e2d400905050f4a92dec1c4bdf797b3fc9b2f8e84a482f3 d800386186712dae00d5c386ec9387a5e9c9a1aca5a573ca91082c7d68421f388e79127a5177d4f8 590237364fd348c9611fa39f78dcdceee3f390f07991b7b47e1daa3ebcb6ccc9607811cb17ce51f1 c8c2c5098dbdd28fca547b3f58c01a424ac05f869f49c6a34672ea2cbbc558428aa1fe48bbfd6115 8b1b735a65d99f21e70dbc020bfdface9f724a0d1fb5895db971cc81aa7608baa0920abb0a565c9c 436e2fd13323428296c86385f2384e408a31e104670df0791d93e743a3a5194ee6b076fb6323ca59 3011b7348c16cf58f66b9633906ba54a2ee803187344b394f75dd2e663a57b956cb830dd7a908d4f 39a2336a61ef9fda549180d4ccde21514d117b6c6fd07a9102b5efe710a32af4eeacae2cb3b1dec0 35b9593b48b9d3ca4c13d245d5f04169b0b1 node b derives the connection secrets for (auth₂, ack₂) as follows: aes-secret = 80e8632c05fed6fc2a13b0f8d31a3cf645366239170ea067065aba8e28bac487 mac-secret = 2ea74ec5dae199227dff1af715362700e989d889d7a493cb0639691efb8e5f98 running b’s ingress-mac keccak state on the string “foo” yields the hash ingress-mac("foo") = 0c7ec6340062cc46f5e9f1e3cf86f8c8c403c5a0964f5df0ebd34a75ddc86db5 copyright copyright and related rights waived via cc0. citation please cite this document as: felix lange , "eip-8: devp2p forward compatibility requirements for homestead," ethereum improvement proposals, no. 8, december 2015. [online serial]. available: https://eips.ethereum.org/eips/eip-8. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7498: nft redeemables ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7498: nft redeemables extension to erc-721 and erc-1155 for onchain and offchain redeemables authors ryan ghods (@ryanio), 0age (@0age), adam montgomery (@montasaurus), stephan min (@stephankmin) created 2023-07-28 discussion link https://ethereum-magicians.org/t/erc-7498-nft-redeemables/15485 requires eip-165, eip-712, eip-721, eip-1155, eip-1271 table of contents abstract motivation specification creating campaigns updating campaigns offer consideration dynamic traits signer redeem function trait redemptions max campaign redemptions metadata uri erc-1155 (semi-fungibles) rationale backwards compatibility test cases reference implementation security considerations copyright abstract this specification introduces a new interface that extends erc-721 and erc-1155 to enable the discovery and use of onchain and offchain redeemables for nfts. onchain getters and events facilitate discovery of redeemable campaigns and their requirements. new onchain mints use an interface that gives context to the minting contract of what was redeemed. for redeeming physical products and goods (offchain redeemables) a redemptionhash and signer can tie onchain redemptions with offchain order identifiers that contain chosen product and shipping information. motivation creators frequently use nfts to create redeemable entitlements for digital and physical goods. however, without a standard interface, it is challenging for users and apps to discover and interact with these nfts in a predictable and standard way. this standard aims to encompass enabling broad functionality for: discovery: events and getters that provide information about the requirements of a redemption campaign onchain: token mints with context of items spent offchain: the ability to associate with ecommerce orders (through redemptionhash) trait redemptions: improving the burn-to-redeem experience with erc-7496 dynamic traits. 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. the token must have the following interface and must return true for erc-165 supportsinterface for 0x1ac61e13, the 4 byte interfaceid of the below. interface ierc7498 { /* events */ event campaignupdated(uint256 indexed campaignid, campaign campaign, string metadatauri); event redemption(uint256 indexed campaignid, uint256 requirementsindex, bytes32 redemptionhash, uint256[] considerationtokenids, uint256[] traitredemptiontokenids, address redeemedby); /* structs */ struct campaign { campaignparams params; campaignrequirements[] requirements; // one requirement must be fully satisfied for a successful redemption } struct campaignparams { uint32 starttime; uint32 endtime; uint32 maxcampaignredemptions; address manager; // the address that can modify the campaign address signer; // null address means no eip-712 signature required } struct campaignrequirements { offeritem[] offer; considerationitem[] consideration; traitredemption[] traitredemptions; } struct traitredemption { uint8 substandard; address token; bytes32 traitkey; bytes32 traitvalue; bytes32 substandardvalue; } /* getters */ function getcampaign(uint256 campaignid) external view returns (campaign memory campaign, string memory metadatauri, uint256 totalredemptions); /* setters */ function createcampaign(campaign calldata campaign, string calldata metadatauri) external returns (uint256 campaignid); function updatecampaign(uint256 campaignid, campaign calldata campaign, string calldata metadatauri) external; function redeem(uint256[] calldata considerationtokenids, address recipient, bytes calldata extradata) external payable; } --/* seaport structs, for reference, used in offer/consideration above */ enum itemtype { native, erc20, erc721, erc1155 } struct offeritem { itemtype itemtype; address token; uint256 identifierorcriteria; uint256 startamount; uint256 endamount; } struct considerationitem extends offeritem { address payable recipient; // (note: psuedocode above, as of this writing can't extend structs in solidity) } struct spentitem { itemtype itemtype; address token; uint256 identifier; uint256 amount; } creating campaigns when creating a new campaign, createcampaign must be used and must return the newly created campaignid along with the campaignupdated event. the campaignid must be a counter incremented with each new campaign. the first campaign must have an id of 1. updating campaigns updates to campaigns may use updatecampaign and must emit the campaignupdated event. if an address other than the manager tries to update the campaign, it must revert with notmanager(). if the manager wishes to make the campaign immutable, the manager may be set to the null address. offer if tokens are set in the params offer, the tokens must implement the iredemptionmintable interface in order to support minting new items. the implementation should be however the token mechanics are desired. the implementing token must return true for erc-165 supportsinterface for the interfaceid of iredemptionmintable, 0x81fe13c2. interface iredemptionmintable { function mintredemption( uint256 campaignid, address recipient, offeritem calldata offer, considerationitem[] calldata consideration, traitredemption[] calldata traitredemptions ) external; } when mintredemption is called, it is recommended to replace the token identifiers in the consideration items and trait redemptions with the items actually being redeemed. consideration any token may be specified in the campaign requirement consideration. this will ensure the token is transferred to the recipient. if the token is meant to be burned, the recipient should be 0x000000000000000000000000000000000000dead. if the token can internally handle burning its own tokens and reducing totalsupply, the token may burn the token instead of transferring to the recipient 0x000000000000000000000000000000000000dead. dynamic traits including trait redemptions is optional, but if the token would like to enable trait redemptions the token must include erc-7496 dynamic traits. signer a signer may be specified to provide a signature to process the redemption. if the signer is not the null address, the signature must recover to the signer address via eip-712 or erc-1271. the eip-712 struct for signing must be as follows: signedredeem(address owner,uint256[] considerationtokenids,uint256[] traitredemptiontokenids,uint256 campaignid,uint256 requirementsindex, bytes32 redemptionhash, uint256 salt)" redeem function the redeem function must use the consideration, offer, and traitredemptions specified by the requirements determined by the campaignid and requirementsindex: execute the transfers in the consideration mutate the traits specified by traitredemptions according to erc-7496 dynamic traits call mintredemption() on every offer item the redemption event must be emitted for every valid redemption that occurs. redemption extradata the extradata layout must conform to the below: bytes value description / notes 0-32 campaignid 32-64 requirementsindex index of the campaign requirements met 64-96 redemptionhash hash of offchain order ids 96-* uint256[] traitredemptiontokenids token ids for trait redemptions, must be in same order of campaign traitredemption[] *-(+32) salt if signer != address(0) *-(+*) signature if signer != address(0). can be for eip-712 or erc-1271 the requirementsindex must be the index in the requirements array that satisfies the redemption. this helps reduce gas to find the requirement met. the traitredemptiontokenids specifies the token ids required for the trait redemptions in the requirements array. the order must be the same order of the token addresses expected in the array of traitredemption structs in the campaign requirement used. if the campaign signer is the null address the salt and signature must be omitted. the redemptionhash is designated for offchain redemptions to reference offchain order identifiers to track the redemption to. the function must check that the campaign is active (using the same boundary check as seaport, starttime <= block.timestamp < endtime). if it is not active, it must revert with notactive(). trait redemptions the token must respect the traitredemption substandards as follows: substandard id description substandard value 1 set value to traitvalue prior required value. if blank, cannot be the traitvalue already 2 increment trait by traitvalue max value 3 decrement trait by traitvalue min value 4 check value is traitvalue n/a max campaign redemptions the token must check that the maxcampaignredemptions is not exceeded. if the redemption does exceed maxcampaignredemptions, it must revert with maxcampaignredemptionsreached(uint256 total, uint256 max) metadata uri the metadata uri must conform to the below json schema: { "$schema": "https://json-schema.org/draft/2020-12/schema", "type": "object", "properties": { "campaigns": { "type": "array", "items": { "type": "object", "properties": { "campaignid": { "type": "number" }, "name": { "type": "string" }, "description": { "type": "string", "description": "a one-line summary of the redeemable. markdown is not supported." }, "details": { "type": "string", "description": "a multi-line or multi-paragraph description of the details of the redeemable. markdown is supported." }, "imageurls": { "type": "array", "items": { "type": "string" }, "description": "a list of image urls for the redeemable. the first image will be used as the thumbnail. will rotate in a carousel if multiple images are provided. maximum 5 images." }, "bannerurl": { "type": "string", "description": "the banner image for the redeemable." }, "faq": { "type": "array", "items": { "type": "object", "properties": { "question": { "type": "string" }, "answer": { "type": "string" }, "required": ["question", "answer"] } } }, "contentlocale": { "type": "string", "description": "the language tag for the content provided by this metadata. https://www.rfc-editor.org/rfc/rfc9110.html#name-language-tags" }, "maxredemptionspertoken": { "type": "string", "description": "the maximum number of redemptions per token. when isburn is true should be 1, else can be a number based on the trait redemptions limit." }, "isburn": { "type": "string", "description": "if the redemption burns the token." }, "uuid": { "type": "string", "description": "an optional unique identifier for the campaign, for backends to identify when draft campaigns are published onchain." }, "productlimitforredemption": { "type": "number", "description": "the number of products which are able to be chosen from the products array for a single redemption." }, "products": { "type": "object", "properties": "https://schema.org/product", "required": ["name", "url", "description"] } }, "required": ["campaignid", "name", "description", "imageurls", "isburn"] } } } } future eips may inherit this one and add to the above metadata to add more features and functionality. erc-1155 (semi-fungibles) this standard may be applied to erc-1155 but the redemptions would apply to all token amounts for specific token identifiers. if the erc-1155 contract only has tokens with amount of 1, then this specification may be used as written. rationale the “offer” and “consideration” structs from seaport were used to create a similar language for redeemable campaigns. the “offer” is what is being offered, e.g. a new onchain token, and the “consideration” is what must be satisfied to complete the redemption. the “consideration” field has a “recipient”, who the token should be transferred to. for trait updates that do not require moving of a token, traitredemptiontokenids is specified instead. the “salt” and “signature” fields are provided primarily for offchain redemptions where a provider would want to sign approval for a redemption before it is conducted onchain, to prevent the need for irregular state changes. for example, if a user lives outside a region supported by the shipping of an offchain redeemable, during the offchain order creation process the signature would not be provided for the onchain redemption when seeing that the user’s shipping country is unsupported. this prevents the user from redeeming the nft, then later finding out the shipping isn’t supported after their nft is already burned or trait is mutated. erc-7496 dynamic traits is used for trait redemptions to support onchain enforcement of trait values for secondary market orders. backwards compatibility as a new eip, no backwards compatibility issues are present. test cases authors have included foundry tests covering functionality of the specification in the assets folder. reference implementation authors have included reference implementations of the specification in the assets folder. security considerations if trait redemptions are desired, tokens implementing this eip must properly implement erc-7496 dynamic traits. for tokens to be minted as part of the params offer, the mintredemption function contained as part of iredemptionmintable must be permissioned and only allowed to be called by specified addresses. copyright copyright and related rights waived via cc0. citation please cite this document as: ryan ghods (@ryanio), 0age (@0age), adam montgomery (@montasaurus), stephan min (@stephankmin), "erc-7498: nft redeemables [draft]," ethereum improvement proposals, no. 7498, july 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7498. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2327: begindata opcode ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-2327: begindata opcode authors martin lundfall (@mrchico) created 2019-10-28 discussion link https://ethereum-magicians.org/t/new-opcode-begindata/3727 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary introduces a new opcode begindata, which indicates that the remaining bytes of the contract should be regarded as data rather than contract code and cannot be executed. abstract it is common for smart contracts to efficiently store data directly in the contract bytecode. examples include constructor arguments, constant variables, compiler metadata and the contract runtime during the init phase. currently, such data is not distinguished from normal bytecode and is still being analysed for jumpdests by evm interpreters. this eip introduces a new opcode begindata at byte 0xb6, which marks the remainding bytecode as data, indicating to evm interpreters, static analysis tools and chain explorers that the remaining bytes do not represent opcodes. motivation the begindata opcode has been suggested before as part of the eip subroutines and static jumps for the evm eip-615 as a way to determine the position of jumptables in contract bytecode. it is here introduced in its own right in order to exclude data from the jumpdest analysis of contracts, making it impossible to jump to data. this makes it easier for static analysis tools to analyse contracts, allows disassemblers, chain explorers and debuggers to not display data as a mess of invalid opcodes and may even provide a marginal improvement in performance. it also helps scalability because it improves on-chain evaluation of transactions from other chains in that the validation that the code conforms to a certain pattern does not need to do a full jumpdest analysis to see that data is not executed and thus does not have to conform to the pattern (used by the optimism project). additionally, it paves the way for suggestions such as eip-1712 to disallow unused opcodes, jumptables eip-615 and speculative proposals to disallow for deployment of contracts with stack usage violations. specification while computing the valid jumpdests of a contract, halt analysis once the first begindata is encountered. in other words: a jump to any codelocation equal to or greater than the location of the first begindata causes a bad_jump_destination error. if begindata is encountered during contract execution, it has the same semantics as stop. it uses 0 gas. bytes past begindata remain accessible via codecopy and extcodecopy. begindata does not influence codesize or extcodesize. rationale the byte 0xb6 was chosen to align with eip-615. the choice to stop if begindata is encountered is somewhat arbitrary. an alternative would be to be to abort the execution with an out-of-gas error. backwards compatibility the proposal will not change any existing contracts unless their current behaviour relies upon the usage of unused opcodes. since contracts have been using data from the very start, in a sense all of them use unused opcodes, but they would have to use data in a way that it is skipped during execution and jumped over. the solidity compiler never generated such code. it has to be evaluated whether contracts created by other means could have such a code structure. test cases test cases should include: 1) a contract which jumps to a destination x, where x has a pc value higher than the begindata opcode, and the byte at x is 0x5b. this should fail with a bad_jump_destination error. 2) a contract which encounters the begindata opcode (should stop executing the current call frame) implementation not yet. copyright copyright and related rights waived via cc0. citation please cite this document as: martin lundfall (@mrchico), "eip-2327: begindata opcode [draft]," ethereum improvement proposals, no. 2327, october 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2327. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-615: subroutines and static jumps for the evm ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-615: subroutines and static jumps for the evm authors greg colvin , brooklyn zelenka (@expede), paweł bylica (@chfast), christian reitwiessner (@chriseth) created 2016-12-10 discussion link https://ethereum-magicians.org/t/eip-615-subroutines-and-static-jumps-for-the-evm-last-call/3472 table of contents simple summary abstract motivation specification dependencies proposal semantics validity backwards compatibility rationale implementation appendix a validation appendix b evm analysis copyright simple summary in the 21st century, on a blockchain circulating billions of eth, formal specification and verification are an essential tool against loss. yet the design of the evm makes this unnecessarily difficult. further, the design of the evm makes near-linear-time compilation to machine code difficult. we propose to move forward with proposals to resolve these problems by tightening evm security guarantees and reducing barriers to performance. abstract evm code is currently difficult to statically analyze, hobbling critical tools for preventing the many expensive bugs our blockchain has experienced. further, none of the current implementations of the ethereum virtual machine—including the compilers—are sufficiently performant to reduce the need for precompiles and otherwise meet the network’s long-term demands. this proposal identifies dynamic jumps as a major reason for these issues, and proposes changes to the evm specification to address the problem, making further efforts towards a safer and more performant the evm possible. we also propose to validate—in near-linear time—that evm contracts correctly use subroutines, avoid misuse of the stack, and meet other safety conditions before placing them on the blockchain. validated code precludes most runtime exceptions and the need to test for them. and well-behaved control flow and use of the stack makes life easier for interpreters, compilers, formal analysis, and other tools. motivation currently the evm supports only dynamic jumps, where the address to jump to is an argument on the stack. worse, the evm fails to provide ordinary, alternative control flow facilities like subroutines and switches provided by wasm and most cpus. so dynamic jumps cannot be avoided, yet they obscure the structure of the code and thus mostly inhibit controland data-flow analysis. this puts the quality and speed of optimized compilation fundamentally at odds. further, since many jumps can potentially be to any jump destination in the code, the number of possible paths through the code can go up as the product of the number of jumps by the number of destinations, as does the time complexity of static analysis. many of these cases are undecidable at deployment time, further inhibiting static and formal analyses. however, given ethereum’s security requirements, near-linear n log n time complexity is essential. otherwise, contracts can be crafted or discovered with quadratic complexity to use as denial of service attack vectors against validations and optimizations. but absent dynamic jumps code can be statically analyzed in linear time. that allows for linear time validation. it also allows for code generation and such optimizations as can be done in log n time to comprise an n log n time compiler. and absent dynamic jumps, and with proper subroutines the evm is a better target for code generation from other languages, including solidity vyper llvm ir front ends include c, c++, common lisp, d, fortran, haskell, java, javascript, kotlin, lua, objective-c, pony, pure, python, ruby, rust, scala, scheme, and swift the result is that all of the following validations and optimizations can be done at deployment time with near-linear (n log n) time complexity. the absence of most exceptional halting states can be validated. the maximum use of resources can be sometimes be calculated. bytecode can be compiled to machine code in near-linear time. compilation can more effectively optimize use of smaller registers. compilation can more effectively optimize injection of gas metering. specification dependencies eip-1702. generalized account versioning scheme. this proposal needs a versioning scheme to allow for its bytecode (and eventually ewasm bytecode) to be deployed with existing bytecode on the same blockchain. proposal we propose to deprecate two existing instructions—jump and jumpi—and propose new instructions to support their legitimate uses. in particular, it must remain possible to compile solidity and vyper code to evm bytecode, with no significant loss of performance or increase in gas price. especially important is efficient translation to and from ewasm and to machine code. to that end we maintain a close correspondence between wasm, x86, arm and proposed evm instructions. eip-615 wasm x86 arm jumpto br jmp b jumpif br_if je beq jumpv br_table jmp tbh jumpsub call call bl jumpsubv call_indirect call bl return return ret ret getlocal local.get pop pop putlocal local.put push push beginsub func begindata tables preliminaries these forms instruction instruction x instruction x, y name an instruction with no, one and two arguments, respectively. an instruction is represented in the bytecode as a single-byte opcode. any arguments are laid out as immediate data bytes following the opcode inline, interpreted as fixed length, msb-first, two’s-complement, two-byte positive integers. (negative values are reserved for extensions.) branches and subroutines the two most important uses of jump and jumpi are static jumps and return jumps. conditional and unconditional static jumps are the mainstay of control flow. return jumps are implemented as a dynamic jump to a return address pushed on the stack. with the combination of a static jump and a dynamic return jump you can—and solidity does—implement subroutines. the problem is that static analysis cannot tell the one place the return jump is going, so it must analyze every possibility (a heavy analysis). static jumps are provided by jumpto jump_target jumpif jump_target which are the same as jump and jumpi except that they jump to an immediate jump_target rather than an address on the stack. to support subroutines, beginsub, jumpsub, and returnsub are provided. brief descriptions follow, and full semantics are given below. beginsub n_args, n_results marks the single entry to a subroutine. n_args items are taken off of the stack at entry to, and n_results items are placed on the stack at return from the subroutine. the subroutine ends at the next beginsub instruction (or begindata, below) or at the end of the bytecode. jumpsub jump_target jumps to an immediate subroutine address. returnsub returns from the current subroutine to the instruction following the jumpsub that entered it. switches, callbacks, and virtual functions dynamic jumps are also used for o(1) indirection: an address to jump to is selected to push on the stack and be jumped to. so we also propose two more instructions to provide for constrained indirection. we support these with vectors of jumpdest or beginsub offsets stored inline, which can be selected with an index on the stack. that constrains validation to a specified subset of all possible destinations. the danger of quadratic blow up is avoided because it takes as much space to store the jump vectors as it does to code the worst case exploit. dynamic jumps to a jumpdest are used to implement o(1) jumptables, which are useful for dense switch statements. wasm and most cpus provide similar instructions. jumpv n, jump_targets jumps to one of a vector of n jumpdest offsets via a zero-based index on the stack. the vector is stored inline at the jump_targets offset after the begindata bytecode as msb-first, two’s-complement, two-byte positive integers. if the index is greater than or equal to n 1 the last (default) offset is used. dynamic jumps to a beginsub are used to implement o(1) virtual functions and callbacks, which take at most two pointer dereferences on most cpus. wasm provides a similar instruction. jumpsubv n, jump_targets jumps to one of a vector of n beginsub offsets via a zero-based index on the stack. the vector is stored inline at the jump_targets offset after the data bytecode, as msb-first, two’s-complement, two-byte positive integers. if the index is greater than or equal to n 1 the last (default) offset is used. variable access these operations provide convenient access to subroutine parameters and local variables at fixed stack offsets within a subroutine. otherwise only sixteen variables can be directly addressed. putlocal n pops the stack to the local variable n. getlocal n pushes the local variable n onto the stack. local variable n is the nth stack item below the frame pointer, fp[-n], as defined below. data there needs to be a way to place unreachable data into the bytecode that will be skipped over and not validated. indirect jump vectors will not be valid code. initialization code must create runtime code from data that might not be valid code. and unreachable data might prove useful to programs for other purposes. begindata specifies that all of the following bytes to the end of the bytecode are data, and not reachable code. structure valid eip-615 evm bytecode begins with a valid header. this is the magic number ‘\0evm’ followed by the semantic versioning number ‘\1\5\0’. (for wasm the header is ‘\0asm\1’). following the header is the beginsub opcode for the main routine. it takes no arguments and returns no values. other subroutines may follow the main routine, and an optional begindata opcode may mark the start of a data section. semantics jumps to and returns from subroutines are described here in terms of the evm data stack, (as defined in the yellow paper) usually just called “the stack.” a return stack of jumpsub and jumpsubv offsets. a frame stack of frame pointers. we will adopt the following conventions to describe the machine state: the program counter pc is (as usual) the byte offset of the currently executing instruction. the stack pointer sp corresponds to the yellow paper’s substate s of the machine state. sp[0] is where a new item is can be pushed on the stack. sp[1] is the first item on the stack, which can be popped off the stack. the stack grows towards lower addresses. the frame pointer fp is set to sp + n_args at entry to the currently executing subroutine. the stack items between the frame pointer and the current stack pointer are called the frame. the current number of items in the frame, fp sp, is the frame size. note: defining the frame pointer so as to include the arguments is unconventional, but better fits our stack semantics and simplifies the remainder of the proposal. the frame pointer and return stacks are internal to the subroutine mechanism, and not directly accessible to the program. this is necessary to prevent the program from modifying its own state in ways that could be invalid. execution of evm bytecode begins with the main routine with no arguments, sp and fp set to 0, and with one value on the return stack—code_size 1. (executing the virtual byte of 0 after this offset causes an evm to stop. thus executing a returnsub with no prior jumpsub or jumbsubv—that is, in the main routine—executes a stop.) execution of a subroutine begins with jumpsub or jumpsubv, which pushes pc on the return stack, pushes fp on the frame stack thus suspending execution of the current subroutine, sets fp to sp + n_args, and sets pc to the specified beginsub address thus beginning execution of the new subroutine. execution of a subroutine is suspended during and resumed after execution of nested subroutines, and ends upon encountering a returnsub, which sets fp to the top of the virtual frame stack and pops the stack, sets sp to fp + n_results, sets pc to top of the return stack and pops the stack, and advances pc to the next instruction thus resuming execution of the enclosing subroutine or main routine. a stop or return also ends the execution of a subroutine. for example, starting from this stack, _________________ | locals 20 = 0 { // check for constant frame size if instruction is jumpdest if -sp != frame_size[pc] return false // return to break cycle return true } frame_size[pc] = -sp // effect of instruction on stack n_removed = removed_items(instructions) n_added = added_items(instruction) // check for stack underflow if -sp < n_removed return false // net effect of removing and adding stack items sp += n_removed sp -= n_added // check for stack overflow if -sp > 1024 return false if instruction is stop, return, or suicide return true // violates single entry if instruction is beginsub return false // return to top or from recursion to jumpsub if instruction is returnsub return true;; if instruction is jumpsub { // check for enough arguments sub_pc = jump_target(pc) if -sp < n_args(sub_pc) return false return true } // reset pc to destination of jump if instruction is jumpto { pc = jump_target(pc) continue } // recurse to jump to code to validate if instruction is jumpif { if not validate_subroutine(jump_target(pc), return_pc, sp) return false } // advance pc according to instruction pc = advance_pc(pc) } // check for right number of results if (-sp != n_results(return_pc) return false return true } appendix b evm analysis there is a large and growing ecosystem of researchers, authors, teachers, auditors, and analytic tools–providing software and services focused on the correctness and security of evm code. a small sample is given here. some tools contract library ethereumj exthereum harmony jeb mythril securify skale status some papers a formal verification tool for ethereum vm bytecode a lem formalization of evm and some isabelle/hol proofs a survey of attacks on ethereum smart contracts defining the ethereum virtual machine for interactive theorem provers ethereum 2.0 specifications formal verification of smart contracts jellopaper: human readable semantics of evm in k kevm: a complete semantics of the ethereum virtual machine. making smart contracts smarter securify: practical security analysis of smart contracts the thunder protocol towards verifying ethereum smart contract bytecode in isabelle/hol *a lem formalization of evm 1.5 copyright copyright and related rights waived via cc0. citation please cite this document as: greg colvin , brooklyn zelenka (@expede), paweł bylica (@chfast), christian reitwiessner (@chriseth), "eip-615: subroutines and static jumps for the evm [draft]," ethereum improvement proposals, no. 615, december 2016. [online serial]. available: https://eips.ethereum.org/eips/eip-615. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-3525: semi-fungible token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-3525: semi-fungible token defines a specification where erc-721 compatible tokens with the same slot and different ids are fungible. authors will wang (@will42w), mike meng , yi cai (@yeetsai) , ryan chow , zhongxin wu (@nerverwind), alvisdu (@alvisdu) created 2020-12-01 requires eip-20, eip-165, eip-721 table of contents abstract motivation specification erc-3525 token receiver token manipulation metadata rationale metadata generation design decision: value transfer from token to address design decision: notification/acceptance mechanism instead of ‘safe transfer’ design decision: relationship between different approval models backwards compatibility reference implementation security considerations copyright abstract this is a standard for semi-fungible tokens. the set of smart contract interfaces described in this document defines an erc-721 compatible token standard. this standard introduces an triple scalar model that represents the semi-fungible structure of a token. it also introduces new transfer models as well as approval models that reflect the semi-fungible nature of the tokens. token contains an erc-721 equivalent id property to identify itself as a universally unique entity, so that the tokens can be transferred between addresses and approved to be operated in erc-721 compatible way. token also contains a value property, representing the quantitative nature of the token. the meaning of the ‘value’ property is quite like that of the ‘balance’ property of an erc-20 token. each token has a ‘slot’ attribute, ensuring that the value of two tokens with the same slot be treated as fungible, adding fungibility to the value property of the tokens. this eip introduces new token transfer models for semi-fungibility, including value transfer between two tokens of the same slot and value transfer from a token to an address. motivation tokenization is one of the most important trends by which to use and control digital assets in crypto. traditionally, there have been two approaches to do so: fungible and non-fungible tokens. fungible tokens generally use the erc-20 standard, where every unit of an asset is identical to each other. erc-20 is a flexible and efficient way to manipulate fungible tokens. non-fungible tokens are predominantly erc-721 tokens, a standard capable of distinguishing digital assets from one another based on identity. however, both have significant drawbacks. for example, erc-20 requires that users create a separate erc-20 contract for each individual data structure or combination of customizable properties. in practice, this results in an extraordinarily large amount of erc-20 contracts that need to be created. on the other hand, erc-721 tokens provide no quantitative feature, significantly undercutting their computability, liquidity, and manageability. for example, if one was to create financial instruments such as bonds, insurance policy, or vesting plans using erc-721, no standard interfaces are available for us to control the value in them, making it impossible, for example, to transfer a portion of the equity in the contract represented by the token. a more intuitive and straightforward way to solve the problem is to create a semi-fungible token that has the quantitative features of erc-20 and qualitative attributes of erc-721. the backwards-compatibility with erc-721 of such semi-fungible tokens would help utilize existing infrastructures already in use and lead to faster adoption. specification the keywords “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. every erc-3525 compliant contract must implement the erc-3525, erc-721 and erc-165 interfaces pragma solidity ^0.8.0; /** * @title erc-3525 semi-fungible token standard * note: the erc-165 identifier for this interface is 0xd5358140. */ interface ierc3525 /* is ierc165, ierc721 */ { /** * @dev must emit when value of a token is transferred to another token with the same slot, * including zero value transfers (_value == 0) as well as transfers when tokens are created * (`_fromtokenid` == 0) or destroyed (`_totokenid` == 0). * @param _fromtokenid the token id to transfer value from * @param _totokenid the token id to transfer value to * @param _value the transferred value */ event transfervalue(uint256 indexed _fromtokenid, uint256 indexed _totokenid, uint256 _value); /** * @dev must emit when the approval value of a token is set or changed. * @param _tokenid the token to approve * @param _operator the operator to approve for * @param _value the maximum value that `_operator` is allowed to manage */ event approvalvalue(uint256 indexed _tokenid, address indexed _operator, uint256 _value); /** * @dev must emit when the slot of a token is set or changed. * @param _tokenid the token of which slot is set or changed * @param _oldslot the previous slot of the token * @param _newslot the updated slot of the token */ event slotchanged(uint256 indexed _tokenid, uint256 indexed _oldslot, uint256 indexed _newslot); /** * @notice get the number of decimals the token uses for value e.g. 6, means the user * representation of the value of a token can be calculated by dividing it by 1,000,000. * considering the compatibility with third-party wallets, this function is defined as * `valuedecimals()` instead of `decimals()` to avoid conflict with erc-20 tokens. * @return the number of decimals for value */ function valuedecimals() external view returns (uint8); /** * @notice get the value of a token. * @param _tokenid the token for which to query the balance * @return the value of `_tokenid` */ function balanceof(uint256 _tokenid) external view returns (uint256); /** * @notice get the slot of a token. * @param _tokenid the identifier for a token * @return the slot of the token */ function slotof(uint256 _tokenid) external view returns (uint256); /** * @notice allow an operator to manage the value of a token, up to the `_value`. * @dev must revert unless caller is the current owner, an authorized operator, or the approved * address for `_tokenid`. * must emit the approvalvalue event. * @param _tokenid the token to approve * @param _operator the operator to be approved * @param _value the maximum value of `_totokenid` that `_operator` is allowed to manage */ function approve( uint256 _tokenid, address _operator, uint256 _value ) external payable; /** * @notice get the maximum value of a token that an operator is allowed to manage. * @param _tokenid the token for which to query the allowance * @param _operator the address of an operator * @return the current approval value of `_tokenid` that `_operator` is allowed to manage */ function allowance(uint256 _tokenid, address _operator) external view returns (uint256); /** * @notice transfer value from a specified token to another specified token with the same slot. * @dev caller must be the current owner, an authorized operator or an operator who has been * approved the whole `_fromtokenid` or part of it. * must revert if `_fromtokenid` or `_totokenid` is zero token id or does not exist. * must revert if slots of `_fromtokenid` and `_totokenid` do not match. * must revert if `_value` exceeds the balance of `_fromtokenid` or its allowance to the * operator. * must emit `transfervalue` event. * @param _fromtokenid the token to transfer value from * @param _totokenid the token to transfer value to * @param _value the transferred value */ function transferfrom( uint256 _fromtokenid, uint256 _totokenid, uint256 _value ) external payable; /** * @notice transfer value from a specified token to an address. the caller should confirm that * `_to` is capable of receiving erc-3525 tokens. * @dev this function must create a new erc-3525 token with the same slot for `_to`, * or find an existing token with the same slot owned by `_to`, to receive the transferred value. * must revert if `_fromtokenid` is zero token id or does not exist. * must revert if `_to` is zero address. * must revert if `_value` exceeds the balance of `_fromtokenid` or its allowance to the * operator. * must emit `transfer` and `transfervalue` events. * @param _fromtokenid the token to transfer value from * @param _to the address to transfer value to * @param _value the transferred value * @return id of the token which receives the transferred value */ function transferfrom( uint256 _fromtokenid, address _to, uint256 _value ) external payable returns (uint256); } the slot’s enumeration extension is optional. this allows your contract to publish its full list of slots and make them discoverable. pragma solidity ^0.8.0; /** * @title erc-3525 semi-fungible token standard, optional extension for slot enumeration * @dev interfaces for any contract that wants to support enumeration of slots as well as tokens * with the same slot. * note: the erc-165 identifier for this interface is 0x3b741b9e. */ interface ierc3525slotenumerable is ierc3525 /* , ierc721enumerable */ { /** * @notice get the total amount of slots stored by the contract. * @return the total amount of slots */ function slotcount() external view returns (uint256); /** * @notice get the slot at the specified index of all slots stored by the contract. * @param _index the index in the slot list * @return the slot at `index` of all slots. */ function slotbyindex(uint256 _index) external view returns (uint256); /** * @notice get the total amount of tokens with the same slot. * @param _slot the slot to query token supply for * @return the total amount of tokens with the specified `_slot` */ function tokensupplyinslot(uint256 _slot) external view returns (uint256); /** * @notice get the token at the specified index of all tokens with the same slot. * @param _slot the slot to query tokens with * @param _index the index in the token list of the slot * @return the token id at `_index` of all tokens with `_slot` */ function tokeninslotbyindex(uint256 _slot, uint256 _index) external view returns (uint256); } the slot level approval is optional. this allows any contract that wants to support approval for slots, which allows an operator to manage one’s tokens with the same slot. pragma solidity ^0.8.0; /** * @title erc-3525 semi-fungible token standard, optional extension for approval of slot level * @dev interfaces for any contract that wants to support approval of slot level, which allows an * operator to manage one's tokens with the same slot. * see https://eips.ethereum.org/eips/eip-3525 * note: the erc-165 identifier for this interface is 0xb688be58. */ interface ierc3525slotapprovable is ierc3525 { /** * @dev must emit when an operator is approved or disapproved to manage all of `_owner`'s * tokens with the same slot. * @param _owner the address whose tokens are approved * @param _slot the slot to approve, all of `_owner`'s tokens with this slot are approved * @param _operator the operator being approved or disapproved * @param _approved identify if `_operator` is approved or disapproved */ event approvalforslot(address indexed _owner, uint256 indexed _slot, address indexed _operator, bool _approved); /** * @notice approve or disapprove an operator to manage all of `_owner`'s tokens with the * specified slot. * @dev caller should be `_owner` or an operator who has been authorized through * `setapprovalforall`. * must emit approvalslot event. * @param _owner the address that owns the erc-3525 tokens * @param _slot the slot of tokens being queried approval of * @param _operator the address for whom to query approval * @param _approved identify if `_operator` would be approved or disapproved */ function setapprovalforslot( address _owner, uint256 _slot, address _operator, bool _approved ) external payable; /** * @notice query if `_operator` is authorized to manage all of `_owner`'s tokens with the * specified slot. * @param _owner the address that owns the erc-3525 tokens * @param _slot the slot of tokens being queried approval of * @param _operator the address for whom to query approval * @return true if `_operator` is authorized to manage all of `_owner`'s tokens with `_slot`, * false otherwise. */ function isapprovedforslot( address _owner, uint256 _slot, address _operator ) external view returns (bool); } erc-3525 token receiver if a smart contract wants to be informed when they receive values from other addresses, it should implement all of the functions in the ierc3525receiver interface, in the implementation it can decide whether to accept or reject the transfer. see “transfer rules” for further detail. pragma solidity ^0.8.0; /** * @title erc-3525 token receiver interface * @dev interface for a smart contract that wants to be informed by erc-3525 contracts when receiving values from any addresses or erc-3525 tokens. * note: the erc-165 identifier for this interface is 0x009ce20b. */ interface ierc3525receiver { /** * @notice handle the receipt of an erc-3525 token value. * @dev an erc-3525 smart contract must check whether this function is implemented by the recipient contract, if the * recipient contract implements this function, the erc-3525 contract must call this function after a * value transfer (i.e. `transferfrom(uint256,uint256,uint256,bytes)`). * must return 0x009ce20b (i.e. `bytes4(keccak256('onerc3525received(address,uint256,uint256, * uint256,bytes)'))`) if the transfer is accepted. * must revert or return any value other than 0x009ce20b if the transfer is rejected. * @param _operator the address which triggered the transfer * @param _fromtokenid the token id to transfer value from * @param _totokenid the token id to transfer value to * @param _value the transferred value * @param _data additional data with no specified format * @return `bytes4(keccak256('onerc3525received(address,uint256,uint256,uint256,bytes)'))` * unless the transfer is rejected. */ function onerc3525received(address _operator, uint256 _fromtokenid, uint256 _totokenid, uint256 _value, bytes calldata _data) external returns (bytes4); } token manipulation scenarios transfer: besides erc-721 compatible token transfer methods, this eip introduces two new transfer models: value transfer from id to id, and value transfer from id to address. function transferfrom(uint256 _fromtokenid, uint256 _totokenid, uint256 _value) external payable; function transferfrom(uint256 _fromtokenid, address _to, uint256 _value) external payable returns (uint256 totokenid_); the first one allows value transfers from one token (specified by _fromtokenid) to another token (specified by _totokenid) within the same slot, resulting in the _value being subtracted from the value of the source token and added to the value of the destination token; the second one allows value transfers from one token (specified by _fromtokenid) to an address (specified by _to), the value is actually transferred to a token owned by the address, and the id of the destination token should be returned. further explanation can be found in the ‘design decision’ section for this method. rules approving rules: this eip provides four kinds of approving functions indicating different levels of approvals, which can be described as full level approval, slot level approval, token id level approval as well as value level approval. setapprovalforall, compatible with erc-721, should indicate the full level of approval, which means that the authorized operators are capable of managing all the tokens, including their values, owned by the owner. setapprovalforslot (optional) should indicate the slot level of approval, which means that the authorized operators are capable of managing all the tokens with the specified slot, including their values, owned by the owner. the token id level approve function, compatible with erc-721, should indicate that the authorized operator is capable of managing only the specified token id, including its value, owned by the owner. the value level approve function, should indicate that the authorized operator is capable of managing the specified maximum value of the specified token owned by the owner. for any approving function, the caller must be the owner or has been approved with a higher level of authority. transferfrom rules: the transferfrom(uint256 _fromtokenid, uint256 _totokenid, uint256 _value) function, should indicate value transfers from one token to another token, in accordance with the rules below: must revert unless msg.sender is the owner of _fromtokenid, an authorized operator or an operator who has been approved the whole token or at least _value of it. must revert if _fromtokenid or _totokenid is zero token id or does not exist. must revert if slots of _fromtokenid and _totokenid do not match. must revert if _value exceeds the value of _fromtokenid or its allowance to the operator. must check for the onerc3525received function if the owner of _totokenid is a smart contract, if the function exists, must call this function after the value transfer, must revert if the result is not equal to 0x009ce20b; must emit transfervalue event. the transferfrom(uint256 _fromtokenid, address _to, uint256 _value) function, which transfers value from one token id to an address, should follow the rule below: must either find a erc-3525 token owned by the address _to or create a new erc-3525 token, with the same slot of _fromtokenid, to receive the transferred value. must revert unless msg.sender is the owner of _fromtokenid, an authorized operator or an operator who has been approved the whole token or at least _value of it. must revert if _fromtokenid is zero token id or does not exist. must revert if _to is zero address. must revert if _value exceeds the value of _fromtokenid or its allowance to the operator. must check for the onerc3525received function if the _to address is a smart contract, if the function exists, must call this function after the value transfer, must revert if the result is not equal to 0x009ce20b; must emit transfer and transfervalue events. metadata metadata extensions erc-3525 metadata extensions are compatible erc-721 metadata extensions. this optional interface can be identified with the erc-165 standard interface detection. pragma solidity ^0.8.0; /** * @title erc-3525 semi-fungible token standard, optional extension for metadata * @dev interfaces for any contract that wants to support query of the uniform resource identifier * (uri) for the erc-3525 contract as well as a specified slot. * because of the higher reliability of data stored in smart contracts compared to data stored in * centralized systems, it is recommended that metadata, including `contracturi`, `sloturi` and * `tokenuri`, be directly returned in json format, instead of being returned with a url pointing * to any resource stored in a centralized system. * see https://eips.ethereum.org/eips/eip-3525 * note: the erc-165 identifier for this interface is 0xe1600902. */ interface ierc3525metadata is ierc3525 /* , ierc721metadata */ { /** * @notice returns the uniform resource identifier (uri) for the current erc-3525 contract. * @dev this function should return the uri for this contract in json format, starting with * header `data:application/json;`. * see https://eips.ethereum.org/eips/eip-3525 for the json schema for contract uri. * @return the json formatted uri of the current erc-3525 contract */ function contracturi() external view returns (string memory); /** * @notice returns the uniform resource identifier (uri) for the specified slot. * @dev this function should return the uri for `_slot` in json format, starting with header * `data:application/json;`. * see https://eips.ethereum.org/eips/eip-3525 for the json schema for slot uri. * @return the json formatted uri of `_slot` */ function sloturi(uint256 _slot) external view returns (string memory); } erc-3525 metadata uri json schema this is the “erc-3525 metadata json schema for contracturi()” referenced above. { "title": "contract metadata", "type": "object", "properties": { "name": { "type": "string", "description": "contract name" }, "description": { "type": "string", "description": "describes the contract" }, "image": { "type": "string", "description": "optional. either a base64 encoded imgae data or a uri pointing to a resource with mime type image/* representing what this contract represents." }, "external_link": { "type": "string", "description": "optional. a uri pointing to an external resource." }, "valuedecimals": { "type": "integer", "description": "the number of decimal places that the balance should display e.g. 18, means to divide the token value by 1000000000000000000 to get its user representation." } } } this is the “erc-3525 metadata json schema for sloturi(uint)” referenced above. { "title": "slot metadata", "type": "object", "properties": { "name": { "type": "string", "description": "identifies the asset category to which this slot represents" }, "description": { "type": "string", "description": "describes the asset category to which this slot represents" }, "image": { "type": "string", "description": "optional. either a base64 encoded imgae data or a uri pointing to a resource with mime type image/* representing the asset category to which this slot represents." }, "properties": { "type": "array", "description": "each item of `properties` should be organized in object format, including name, description, value, order (optional), display_type (optional), etc." "items": { "type": "object", "properties": { "name": { "type": "string", "description": "the name of this property." }, "description": { "type": "string", "description": "describes this property." } "value": { "description": "the value of this property, which may be a string or a number." }, "is_intrinsic": { "type": "boolean", "description": "according to the definition of `slot`, one of the best practice to generate the value of a slot is utilizing the `keccak256` algorithm to calculate the hash value of multi properties. in this scenario, the `properties` field should contain all the properties that are used to calculate the value of `slot`, and if a property is used in the calculation, is_intrinsic must be true." }, "order": { "type": "integer", "description": "optional, related to the value of is_intrinsic. if is_intrinsic is true, it must be the order of this property appeared in the calculation method of the slot." }, "display_type": { "type": "string", "description": "optional. specifies in what form this property should be displayed." } } } } } } this is the “erc-3525 metadata json schema for tokenuri(uint)” referenced above. { "title": "token metadata", "type": "object", "properties": { "name": { "type": "string", "description": "identifies the asset to which this token represents" }, "description": { "type": "string", "description": "describes the asset to which this token represents" }, "image": { "type": "string", "description": "either a base64 encoded imgae data or a uri pointing to a resource with mime type image/* representing the asset to which this token represents." }, "balance": { "type": "integer", "description": "the value held by this token." }, "slot": { "type": "integer", "description": "the id of the slot that this token belongs to." }, "properties": { "type": "object", "description": "arbitrary properties. values may be strings, numbers, objects or arrays. optional, you can use the same schema as the properties section of erc-3525 metadata json schema for sloturi(uint) if you need a better description attribute." } } } rationale metadata generation this token standard is designed to represent semi-fungible assets, which are most suited for financial instruments rather than collectibles or in-game items. for maximum transparency and safety of digital assets, we strongly recommend that all implementations should generate metadata directly from contract code rather than giving out an off-chain server url. design decision: value transfer from token to address the ‘value’ of a token is a property of the token and is not linked to an address, so to transfer the value to an address would be actually transferring it to a token owned by that address, not the address itself. from the implementation perspective, the process of transferring values from token to address could be done as follows: (1) create a new token for the recipient’s address, (2) transfer the value to the new token from the ‘source token’. so that this method is not fully independent from the id-to-id transfer method, and can be viewed as syntactic sugar that wraps the process described above. in a special case, if the destination address owns one or more tokens with the same slot value as the source token, this method will have an alternative implementation as follows: (1) find one token owned by the address with the same slot value of the source token, (2) transfer the value to the found token. both implementations described above should be treated as compliant with this standard. the purpose of maintaining id-to-address transfer function is to maximize the compatibility with most wallet apps, since for most of the token standards, the destination of token transfer are addresses. this syntactic wrapping will help wallet apps easily implement the value transfer function from a token to any address. design decision: notification/acceptance mechanism instead of ‘safe transfer’ erc-721 and some later token standards introduced ‘safe transfer’ model, for better control of the ‘safety’ when transferring tokens, this mechanism leaves the choice of different transfer modes (safe/unsafe) to the sender, and may cause some potential problems: in most situations the sender does not know how to choose between two kinds of transfer methods (safe/unsafe); if the sender calls the safetransferfrom method, the transfer may fail if the recipient contract did not implement the callback function, even if that contract is capable of receiving and manipulating the token without issue. this eip defines a simple ‘check, notify and response’ model for better flexibility as well as simplicity: no extra safetransferfrom methods are needed, all callers only need to call one kind of transfer; all erc-3525 contracts must check for the existence of onerc3525received on the recipient contract and call the function when it exists; any smart contract can implement onerc3525received function for the purpose of being notified after receiving values; this function must return 0x009ce20b (i.e. bytes4(keccak256('onerc3525received(address,uint256,uint256,uint256,bytes)'))) if the transfer is accepted, or any other value if the transfer is rejected. there is a special case for this notification/acceptance mechanism: since erc-3525 allows value transfer from an address to itself, when a smart contract which implements onerc3525received transfers value to itself, onerc3525received will also be called. this allows for the contract to implement different rules of acceptance between self-value-transfer and receiving value from other addresses. design decision: relationship between different approval models for semantic compatibility with erc-721 as well as the flexibility of value manipulation of tokens, we decided to define the relationships between some of the levels of approval like that: approval of an id will lead to the ability to partially transfer values from this id by the approved operator; this will simplify the value approval for an id. however, the approval of total values in a token should not lead to the ability to transfer the token entity by the approved operator. setapprovalforall will lead to the ability to partially transfer values from any token, as well as the ability to approve partial transfer of values from any token to a third party; this will simplify the value transfer and approval of all tokens owned by an address. backwards compatibility as mentioned in the beginning, this eip is backward compatible with erc-721. reference implementation erc-3525 implementation security considerations the value level approval and slot level approval (optional) is isolated from erc-721 approval models, so that approving value should not affect erc-721 level approvals. implementations of this eip must obey this principle. since this eip is erc-721 compatible, any wallets and smart contracts that can hold and manipulate standard erc-721 tokens will have no risks of asset loss for erc-3525 tokens due to incompatible standards implementations. copyright copyright and related rights waived via cc0. citation please cite this document as: will wang (@will42w), mike meng , yi cai (@yeetsai) , ryan chow , zhongxin wu (@nerverwind), alvisdu (@alvisdu), "erc-3525: semi-fungible token," ethereum improvement proposals, no. 3525, december 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3525. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. from inside ethereum ðξvhub berlin | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search from inside ethereum ðξvhub berlin posted by gavin wood on december 2, 2014 research & development yesterday was the first proper day of ðξvhub berlin being open, following the first ethereum internal developers' symposium ðξvcon-0. i want to post a few images to let you gauge the mood here. henning, marek, viktor and felix hacking on the couch aeron and brian in discussion alex and jutta conferencing over network and security the rest of the team hacking in the lab previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-3014: eth_symbol json-rpc method ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3014: eth_symbol json-rpc method authors peter grassberger (@petertheone) created 2020-09-30 discussion link https://github.com/ethereum/eips/issues/3012 table of contents simple summary abstract motivation specification rationale security considerations copyright simple summary add eth_symbol method to the json-rpc that returns the symbol of the native coin of the network. abstract the new method eth_symbol (eth_-namespaced) has no parameters and returns a string of the native coin of the network. for the ethereum mainnet this will be eth, other networks will have other symbols. motivation wallets that deal with multiple networks need some basic information for every blockchain that they connect to. one of those things is the symbol of the native coin of the network. instead of requiring the user to research and manually add the symbol it could be provided to the wallet via this proposed json-rpc endpoint and used automatically. there are lists of networks with symbols like https://github.com/ethereum-lists/chains where a user can manually look up the correct values. but this information could easily come from the network itself. specification method: eth_symbol. params: none. returns: result the native coin symbol, string example: curl -x post --data '{"jsonrpc":"2.0","method":"eth_symbol","params":[],"id":1}' // result { "id": 1, "jsonrpc": "2.0", "result": "eth" } rationale this endpoint is similar to eip-695 but it provides the symbol instead of chainid. it provides functionality that is already there for erc-20 tokens, but not yet for the native coin of the network. alternative naming of eth_nativecurrencysymbol was considered, but the context and the fact that it just returns one value makes it clear that that it returns the symbol for the native coin of the network. security considerations it is a read only endpoint. the information is only as trusted as the json-rpc node itself, it could supply wrong information and thereby trick the user in believing he/she is dealing with another native coin. copyright copyright and related rights waived via cc0. citation please cite this document as: peter grassberger (@petertheone), "eip-3014: eth_symbol json-rpc method [draft]," ethereum improvement proposals, no. 3014, september 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3014. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. on abstraction | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search on abstraction posted by vitalik buterin on july 5, 2015 research & development special thanks to gavin wood, vlad zamfir, our security auditors and others for some of the thoughts that led to the conclusions described in this post one of ethereum's goals from the start, and arguably its entire raison d'être, is the high degree of abstraction that the platform offers. rather than limiting users to a specific set of transaction types and applications, the platform allows anyone to create any kind of blockchain application by writing a script and uploading it to the ethereum blockchain. this gives an ethereum a degree of future-proof-ness and neutrality much greater than that of other blockchain protocols: even if society decides that blockchains aren't really all that useful for finance at all, and are only really interesting for supply chain tracking, self-owning cars and self-refilling dishwashers and playing chess for money in a trust-free form, ethereum will still be useful. however, there still are a substantial number of ways in which ethereum is not nearly as abstract as it could be. cryptography currently, ethereum transactions are all signed using the ecdsa algorithm, and specifically bitcoin's secp256k1 curve. elliptic curve signatures are a popular kind of signature today, particularly because of the smaller signature and key sizes compared to rsa: an elliptic curve signature takes only 65 bytes, compared to several hundred bytes for an rsa signature. however, it is becoming increasingly understood that the specific kind of signature used by bitcoin is far from optimal; ed25519 is increasingly recognized as a superior alternative particularly because of its simpler implementation, greater hardness against side-channel attacks and faster verification. and if quantum computers come around, we will likely have to move to lamport signatures. one suggestion that some of our security auditors, and others, have given us is to allow ed25519 signatures as an option in 1.1. but what if we can stay true to our spirit of abstraction and go a bit further: let people use whatever cryptographic verification algorithm that they want? is that even possible to do securely? well, we have the ethereum virtual machine, so we have a way of letting people implement arbitrary cryptographic verification algorithms, but we still need to figure out how it can fit in. here is a possible approach: every account that is not a contract has a piece of "verification code" attached to it. when a transaction is sent, it must now explicitly specify both sender and recipient. the first step in processing a transaction is to call the verification code, using the transaction's signature (now a plain byte array) as input. if the verification code outputs anything nonempty within 50000 gas, the transaction is valid. if it outputs an empty array (ie. exactly zero bytes; a single \x00 byte does not count) or exits with an exception condition, then it is not valid. to allow people without eth to create accounts, we implement a protocol such that one can generate verification code offline and use the hash of the verification code as an address. people can send funds to that address. the first time you send a transaction from that account, you need to provide the verification code in a separate field (we can perhaps overload the nonce for this, since in all cases where this happens the nonce would be zero in any case) and the protocol (i) checks that the verification code is correct, and (ii) swaps it in (this is roughly equivalent to "pay-to-script-hash" in bitcoin). this approach has a few benefits. first, it does not specify anything about the cryptographic algorithm used or the signature format, except that it must take up at most 50000 gas (this value can be adjusted up or down over time). second, it still keeps the property of the existing system that no pre-registration is required. third, and quite importantly, it allows people to add higher-level validity conditions that depend on state: for example, making transactions that spend more gavcoin than you currently have actually fail instead of just going into the blockchain and having no effect. however, there are substantial changes to the virtual machine that would have to be made for this to work well. the current virtual machine is designed well for dealing with 256-bit numbers, capturing the hashes and elliptic curve signatures that are used right now, but is suboptimal for algorithms that have different sizes. additionally, no matter how well-designed the vm is right now, it fundamentally adds a layer of abstraction between the code and the machine. hence, if this will be one of the uses of the vm going forward, an architecture that maps vm code directly to machine code, applying transformations in the middle to translate specialized opcodes and ensure security, will likely be optimal particularly for expensive and exotic cryptographic algorithms like zk-snarks. and even then, one must take care to minimize any "startup costs" of the virtual machine in order to further increase efficiency as well as denial-of-service vulnerability; together with this, a gas cost rule that encourages re-using existing code and heavily penalizes using different code for every account, allowing just-in-time-compiling virtual machines to maintain a cache, may also be a further improvement. the trie perhaps the most important data structure in ethereum is the patricia tree. the patricia tree is a data structure that, like the standard binary merkle tree, allows any piece of data inside the trie to be securely authenticated against a root hash using a logarithmically sized (ie. relatively short) hash chain, but also has the important property that data can be added, removed or modified in the tree extremely quickly, only making a small number of changes to the entire structure. the trie is used in ethereum to store transactions, receipts, accounts and particularly importantly the storage of each account. one of the often cited weaknesses of this approach is that the trie is one particular data structure, optimized for a particular set of use cases, but in many cases accounts will do better with a different model. the most common request is a heap: a data structure to which elements can quickly be added with a priority value, and from which the lowest-priority element can always be quickly removed particularly useful in implementations of markets with bid/ask offers. right now, the only way to do this is a rather inefficient workaround: write an implementation of a heap in solidity or serpent on top of the trie. this essentially means that every update to the heap requires a logarithmic number of updates (eg. at 1000 elements, ten updates, at 1000000 elements, twenty updates) to the trie, and each update to the trie requires changes to a logarithmic number (once again ten at 1000 elements and twenty at 1000000 elements) of items, and each one of those requires a change to the leveldb database which uses a logarithmic-time-updateable trie internally. if contracts had the option to have a heap instead, as a direct protocol feature, then this overhead could be cut down substantially. one option to solve this problem is the direct one: just have an option for contracts to have either a regular trie or a heap, and be done with it. a seemingly nicer solution, however, is to generalize even further. the solution here is as follows. rather than having a trie or a treap, we simply have an abstract hash tree: there is a root node, which may be empty or which may be the hash of one or more children, and each child in turn may either be a terminal value or the hash of some set of children of its own. an extension may be to allow nodes to have both a value and children. this would all be encoded in rlp; for example, we may stipulate that all nodes must be of the form: [val, child1, child2, child3....] where val must be a string of bytes (we can restrict it to 32 if desired), and each child (of which there can be zero or more) must be the 32 byte sha3 hash of some other node. now, we have the virtual machine's execution environment keep track of a "current node" pointer, and add a few opcodes: getval: pushes the value of the node at the current pointer onto the stack setval: sets the value at the of the node at the current pointer to the value at the top of the stack getchildcount: gets the number of children of the node addchild: adds a new child node (starting with zero children of its own) removechild: pops off a child node descend: descend to the kth child of the current node (taking k as an argument from the stack) ascend: ascend to the parent ascendroot: ascend to the root node accessing a merkle tree with 128 elements would thus look like this: def access(i): ~ascendroot() return _access(i, 7) def _access(i, depth): while depth > 0: ~descend(i % 2) i /= 2 depth -= 1 return ~getval() creating the tree would look like this: def create(vals): ~ascendroot() while ~getchildcount() > 0: ~removechild() _create(vals, 7) def _create(vals:arr, depth): if depth > 0: # recursively create left child ~addchild() ~descend(0) _create(slice(vals, 0, 2**(depth 1)), depth 1) ~ascend() # recursively create right child ~addchild() ~descend(1) _create(slice(vals, 2**(depth 1), 2**depth), depth 1) ~ascend() else: ~setval(vals[0]) clearly, the trie, the treap and in fact any other tree-like data structure could thus be implemented as a library on top of these methods. what is particularly interesting is that each individual opcode is constant-time: theoretically, each node can keep track of the pointers to its children and parent on the database level, requiring only one level of overhead. however, this approach also comes with flaws. particularly, note that if we lose control of the structure of the tree, then we lose the ability to make optimizations. right now, most ethereum clients, including c++, go and python, have a higher-level cache that allows updates to and reads from storage to happen in constant time if there are multiple reads and writes within one transaction execution. if tries become de-standardized, then optimizations like these become impossible. additionally, each individual trie structure would need to come up with its own gas costs and its own mechanisms for ensuring that the tree cannot be exploited: quite a hard problem, given that even our own trie had a medium level of vulnerability until recently when we replaced the trie keys with the sha3 hash of the key rather than the actual key. hence, it's unclear whether going this far is worth it. currency it's well-known and established that an open blockchain requires some kind of cryptocurrency in order to incentivize people to participate in the consensus process; this is the kernel of truth behind this otherwise rather silly meme: however, can we create a blockchain that does not rely on any specific currency, instead allowing people to transact using whatever currency they wish? in a proof of work context, particularly a fees-only one, this is actually relatively easy to do for a simple currency blockchain; just have a block size limit and leave it to miners and transaction senders themselves to come to some equilibrium over the transaction price (the transaction fees may well be done as a batch payment via credit card). for ethereum, however, it is slightly more complicated. the reason is that ethereum 1.0, as it stands, comes with a built-in gas mechanism which allows miners to safely accept transactions without fear of being hit by denial-of-service attacks; the mechanism works as follows: every transaction specifies a max gas count and a fee to pay per unit gas. suppose that the transaction allows itself a gas limit of n. if the transaction is valid, and takes less than n computational steps (say, m computational steps), then it pays m steps worth of the fee. if the transaction consumes all n computational steps before finishing, the execution is reverted but it still pays n steps worth of the fee. this mechanism relies on the existence of a specific currency, eth, which is controlled by the protocol. can we replicate it without relying on any one particular currency? as it turns out, the answer is yes, at least if we combine it with the "use any cryptography you want" scheme above. the approach is as follows. first, we extend the above cryptography-neutrality scheme a bit further: rather than having a separate concept of "verification code" to decide whether or not a particular transaction is valid, simply state that there is only one type of account a contract, and a transaction is simply a message coming in from the zero address. if the transaction exits with an exceptional condition within 50000 gas, the transaction is invalid; otherwise it is valid and accepted. within this model, we then set up accounts to have the following code: check if the transaction is correct. if not, exit. if it is, send some payment for gas to a master contract that will later pay the miner. send the actual message. send a message to ping the master contract. the master contract then checks how much gas is left, and refunds a fee corresponding to the remaining amount to the sender and sends the rest to the miner. step 1 can be crafted in a standardized form, so that it clearly consumes less than 50000 gas. step 3 can similarly be constructed. step 2 can then have the message provide a gas limit equal to the transaction's specified gas limit minus 100000. miners can then pattern-match to only accept transactions that are of this standard form (new standard forms can of course be introduced over time), and they can be sure that no single transaction will cheat them out of more than 50000 steps of computational energy. hence, everything becomes enforced entirely by the gas limit, and miners and transaction senders can use whatever currency they want. one challenge that arises is: how do you pay contracts? currently, contracts have the ability to "charge" for services, using code like this registry example: def reserve(_name:bytes32): if msg.value > 100 * 10**18: if not self.domains[_name].owner: self.domains[_name].owner = msg.sender with a sub-currency, there is no such clear mechanism of tying together a message and a payment for that message. however, there are two general patterns that can act as a substitute. the first is a kind of "receipt" interface: when you send a currency payment to someone, you have the ability to ask the contract to store the sender and value of the transaction. something like registrar.reserve("blahblahblah.eth") would thus be replaced by: gavcoin.sendwithreceipt(registrar, 100 * 10**18) registrar.reserve("blahblahblah.eth") the currency would have code that looks something like this: def sendwithreceipt(to, value): if self.balances[msg.sender] >= value: self.balances[msg.sender] -= value self.balances[to] += value self.last_sender = msg.sender self.last_recipient = to self.last_value = value def getlastreceipt(): return([self.last_sender, self.last_recipient, self.value]:arr) and the registrar would work like this: def reserve(_name:bytes32): r = gavcoin.getlastreceipt(outitems=3) if r[0] == msg.sender and r[1] == self and r[2] >= 100 * 10**18: if not self.domains[_name].owner: self.domains[_name].owner = msg.sender essentially, the registrar would check the last payment made in that currency contract, and make sure that it is a payment to itself. in order to prevent double-use of a payment, it may make sense to have the get_last_receipt method destroy the receipt in the process of reading it. the other pattern is to have a currency have an interface for allowing another address to make withdrawals from your account. the code would then look as follows on the caller side: first, approve a one-time withdrawal of some number of currency units, then reserve, and the reservation contract attempts to make the withdrawal and only goes forward if the withdrawal succeeds: gavcoin.approveonce(registrar, 100) registrar.reserve("blahblahblah.eth") and the registrar would be: def reserve(_name:bytes32): if gavcoin.sendcoinfrom(msg.sender, 100, self) == success: if not self.domains[_name].owner: self.domains[_name].owner = msg.sender the second pattern has been standardized at the standardized contract apis wiki page. currency-agnostic proof of stake the above allows us to create a completely currency-agnostic proof-of-work blockchain. however, to what extent can currency-agnosticism be added to proof of stake? currency-agnostic proof of stake is useful for two reasons. first, it creates a stronger impression of economic neutrality, which makes it more likely to be accepted by existing established groups as it would not be seen as favoring a particular specialized elite (bitcoin holders, ether holders, etc). second, it increases the amount that will be deposited, as individuals holding digital assets other than ether would have a very low personal cost in putting some of those assets into a deposit contract. at first glance, it seems like a hard problem: unlike proof of work, which is fundamentally based on an external and neutral resource, proof of stake is intrinsically based on some kind of currency. so how far can we go? the first step is to try to create a proof of stake system that works using any currency, using some kind of standardized currency interface. the idea is simple: anyone would be able to participate in the system by putting up any currency as a security deposit. some market mechanism would then be used in order to determine the value of each currency, so as to estimate the amount of each currency that would need to be put up in order to obtain a stake depositing slot. a simple first approximation would be to maintain an on-chain decentralized exchange and read price feeds; however, this ignores liquidity and sockpuppet issues (eg. it's easy to create a currency and spread it across a small group of accounts and pretend that it has a value of $1 trillion per unit); hence, a more coarse-grained and direct mechanism is required. to get an idea of what we are looking for, consider david friedman's description of one particular aspect of the ancient athenian legal system: the athenians had a straightforward solution to the problem of producing public goods such as the maintainance of a warship or the organizing of a public festival. if you were one of the richest athenians, every two years you were obligated to produce a public good; the relevant magistrate would tell you which one. "as you doubtless know, we are sending a team to the olympics this year. congratulations, you are the sponsor." or "look at that lovely trireme down at the dock. this year guess who gets to be captain and paymaster." such an obligation was called a liturgy. there were two ways to get out of it. one was to show that you were already doing another liturgy this year or had done one last year. the other was to prove that there was another athenian, richer than you, who had not done one last year and was not doing one this year. this raises an obvious puzzle. how, in a world without accountants, income tax, public records of what people owned and what it was worth, do i prove that you are richer than i am? the answer is not an accountant’s answer but an economist’s—feel free to spend a few minutes trying to figure it out before you turn the page. the solution was simple. i offer to exchange everything i own for everything you own. if you refuse, you have admitted that you are richer than i am, and so you get to do the liturgy that was to be imposed on me. here, we have a rather nifty scheme for preventing people that are rich from pretending that they are poor. now, however, what we are looking for is a scheme for preventing people that are poor from pretending that they are rich (or more precisely, preventing people that are releasing small amounts of value into the proof of stake security deposit scheme from pretending that they are staking a much larger amount). a simple approach would be a swapping scheme like that, but done in reverse via a voting mechanic: in order to join the stakeholder pool, you would need to be approved by 33% of the existing stakeholders, but every stakeholder that approves you would have to face the condition that you can exchange your stake for theirs: a condition that they would not be willing to meet if they thought it likely that the value of your stake actually would drop. stakeholders would then charge an insurance fee for signing stake that is likely to strongly drop against the existing currencies that are used in the stake pool. this scheme as described above has two substantial flaws. first, it naturally leads to currency centralization, as if one currency is dominant it will be most convenient and safe to also stake in that currency. if there are two assets, a and b, the process of joining using currency a, in this scheme, implies receiving an option (in the financial sense of the term) to purchase b at the exchange rate of a:b at the price at the time of joining, and this option would thus naturally have a cost (which can be estimated via the black-scholes model). just joining with currency a would be simpler. however, this can be remedied by asking stakeholders to continually vote on the price of all currencies and assets used in the stake pool an incentivized vote, as the vote reflects both the weight of the asset from the point of view of the system and the exchange rate at which the assets can be forcibly exchanged. a second, more serious flaw, however, is the possibility of pathological metacoins. for example, one can imagine a currency which is backed by gold, but which has the additional rule, imposd by the institution backing it, that forcible transfers initiated by the protocol "do not count"; that is, if such a transfer takes place, the allocation before the transfer is frozen and a new currency is created using that allocation as its starting point. the old currency is no longer backed by gold, and the new one is. athenian forcible-exchange protocols can get you far when you can actually forcibly exchange property, but when one can deliberately create pathological assets that arbitrarily circumvent specific transaction types it gets quite a bit harder. theoretically, the voting mechanism can of course get around this problem: nodes can simply refuse to induct currencies that they know are suspicious, and the default strategy can tend toward conservatism, accepting a very small number of currencies and assets only. altogether, we leave currency-agnostic proof of stake as an open problem; it remains to be seen exactly how far it can go, and the end result may well be some quasi-subjective combination of trustdavis and ripple consensus. sha3 and rlp now, we get to the last few parts of the protocol that we have not yet taken apart: the hash algorithm and the serialization algorithm. here, unfortunately, abstracting things away is much harder, and it is also much harder to tell what the value is. first of all, it is important to note that even though we have shows how we could conceivably abstract away the trees that are used for account storage, it is much harder to see how we could abstract away the trie on the top level that keeps track of the accounts themselves. this tree is necessarily system-wide, and so one can't simply say that different users will have different versions of it. the top-level trie relies on sha3, so some kind of specific hashing algorithm there must stay. even the bottom-level data structures will likely have to stay sha3, since otherwise there would be a risk of a hash function being used that is not collision-resistant, making the whole thing no longer strongly cryptographically authenticated and perhaps leading to forks between full clients and light clients. rlp is similarly unavoiable; at the very least, each account needs to have code and storage, and the two need to be stored together some how, and that is already a serialization format. fortunately, however, sha3 and rlp are perhaps the most well-tested, future-proof and robust parts of the protocol, so the benefit from switching to something else is quite small. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-3374: predictable proof-of-work (pow) sunsetting ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-3374: predictable proof-of-work (pow) sunsetting authors query0x (@query0x) created 2021-03-13 discussion link https://ethereum-magicians.org/t/eip-3374-predictable-proof-of-work-sunsetting table of contents simple summary abstract motivation specification constants block reward rationale backwards compatibility security considerations copyright simple summary sets block reward to 3 and reduces it to 1 linearly over the course of about 1 year. abstract sets the block reward to 3 eth and then incrementally decreases it every block for 2,362,000 blocks (approximately 1 year) until it reaches 1 eth. motivation unnecessarily abrupt changes to the ethereum ecosystem cause disruption and disharmony resulting in the disenfranchisement of community members while undermining stability and confidence. while moves from proof-of-work to proof-of-stake will undoubtedly cause friction between those community members vested in either, all benefit from a measured, predictable transition. this proposal: 1) is issuance neutral over 1 year, and reduces issuance beyond that. 2) sets an initial block reward of 3; 3) introduces an ongoing, predictable reduction in future mining rewards down to 1, effectively “sunsetting” pow and codifying the move to pos; 4) reduces economic incentives for continued development of asics; 5) allows the impacts of decreasing miner rewards to be measured and monitored rather than relying on conjecture and game theory, so adjustments can be made if necessary. specification constants transition_start_block_number: tbd transition_duration: 2_362_000 // (about one year) transition_end_block_number: fork_block_number + transition_duration starting_reward: 3_000_000_000_000_000_000 ending_reward: 1_000_000_000_000_000_000 reward_delta: starting_reward ending_reward block reward if block.number >= transition_end_block_number: block_reward = ending_reward elif block.number == transition_start_block_number: block_reward = starting_reward elif block.number > transition_start_block_number: block_reward = starting_reward reward_delta * transition_duration / (block.number transition_start_block_number) rationale picking starting and ending block reward values that are equidistant from the current block reward rate of 2 ensures the impact of this eip will be issuance neutral over the one year time frame. temporarily raising the block reward to 3 blunts the initial impact of a sudden miner revenue decrease and the continual reductions thereafter codify ethereum’s move to pos by increasingly disincentivizing pow. importantly, this approach moderates the rate of change so impacts and threats can be measured and monitored. backwards compatibility there are no known backward compatibility issues with the introduction of this eip. security considerations there are no known security issues with the introduction of this eip. copyright copyright and related rights waived via cc0. citation please cite this document as: query0x (@query0x), "eip-3374: predictable proof-of-work (pow) sunsetting [draft]," ethereum improvement proposals, no. 3374, march 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3374. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-706: devp2p snappy compression ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: networking eip-706: devp2p snappy compression authors péter szilágyi created 2017-09-07 table of contents abstract motivation specification avoiding dos attacks alternatives (discarded) backwards compatibility implementation test vectors go python references copyright abstract the base networking protocol (devp2p) used by ethereum currently does not employ any form of compression. this results in a massive amount of bandwidth wasted in the entire network, making both initial sync as well as normal operation slower and laggier. this eip proposes a tiny extension to the devp2p protocol to enable snappy compression on all message payloads after the initial handshake. after extensive benchmarks, results show that data traffic is decreased by 60-80% for initial sync. you can find exact numbers below. motivation synchronizing the ethereum main network (block 4,248,000) in geth using fast sync currently consumes 1.01gb upload and 33.59gb download bandwidth. on the rinkeby test network (block 852,000) it’s 55.89mb upload and 2.51gb download. however, most of this data (blocks, transactions) are heavily compressible. by enabling compression at the message payload level, we can reduce the previous numbers to 1.01gb upload / 13.46gb download on the main network, and 46.21mb upload / 463.65mb download on the test network. the motivation behind doing this at the devp2p level (opposed to eth for example) is that it would enable compression for all sub-protocols (eth, les, bzz) seamlessly, reducing any complexity those protocols might incur in trying to individually optimize for data traffic. specification bump the advertised devp2p version number from 4 to 5. if during handshake, the remote side advertises support only for version 4, run the exact same protocol as until now. if the remote side advertises a devp2p version >= 5, inject a snappy compression step right before encrypting the devp2p message during sending: a message consists of {code, size, payload} compress the original payload with snappy and store it in the same field. update the message size to the length of the compressed payload. encrypt and send the message as before, oblivious to compression. similarly to message sending, when receiving a devp2p v5 message from a remote node, insert a snappy decompression step right after the decrypting the devp2p message: a message consists of {code, size, payload} decrypt the message payload as before, oblivious to compression. decompress the payload with snappy and store it in the same field. update the message size to the length of the decompressed payload. important caveats: the handshake message is never compressed, since it is needed to negotiate the common version. snappy framing is not used, since the devp2p protocol already message oriented. note: snappy supports uncompressed binary literals (up to 4gb) too, leaving room for fine-tuned future optimisations for already compressed or encrypted data that would have no gain of compression (snappy usually detects this case automatically). avoiding dos attacks currently a devp2p message length is limited to 24 bits, amounting to a maximum size of 16mb. with the introduction of snappy compression, care must be taken not to blindly decompress messages, since they may get significantly larger than 16mb. however, snappy is capable of calculating the decompressed size of an input message without inflating it in memory (the stream starts with the uncompressed length up to a maximum of 2^32 1 stored as a little-endian varint). this can be used to discard any messages which decompress above some threshold. the proposal is to use the same limit (16mb) as the threshold for decompressed messages. this retains the same guarantees that the current devp2p protocol does, so there won’t be surprises in application level protocols. alternatives (discarded) alternative solutions to data compression that have been brought up and discarded are: extend protocol xyz to support compressed messages versus doing it at devp2p level: pro: can be better optimized when to compress and when not to. con: mixes in transport layer encoding into application layer logic. con: makes the individual message specs more convoluted with compression details. con: requires cross client coordination on every single protocol, making the effor much harder and repeated (eth, les, shh, bzz). introduce seamless variations of protocol such as xyz expanded with xyz-compressed: pro: can be done (hacked in) without cross client coordination. con: litters the network with client specific protocol announces. con: needs to be specced in an eip for cross interoperability anyway. other ideas that have been discussed and discarded: don’t explicitly limit the decompressed message size, only the compressed one: pro: allows larger messages to traverse through devp2p. con: upper layer protocols need to check and discard large messages. con: needs lazy decompression to allow size limitations without dos. backwards compatibility this proposal is fully backward compatible. clients upgrading to the proposed devp2p protocol version 5 should still support skipping the compression step for connections that only advertise version 4 of the devp2p protocol. implementation you can find a reference implementation of this eip in https://github.com/ethereum/go-ethereum/pull/15106. test vectors there is more than one valid encoding of any given input, and there is more than one good internal compression algorithm within snappy when trading off throughput for output size. as such, different implementations might produce slight variations in the compressed form, but all should be cross compatible between each other. as an example, take hex encoded rlp of block #272621 from the rinkeby test network: block.rlp (~3mb). encoding the raw rlp via go’s snappy library yields: block.go.snappy (~70kb). encoding the raw rlp via python’s snappy library yields: block.py.snappy (~70kb). you can verify that an encoded binary can be decoded into the proper plaintext using the following snippets: go $ go get https://github.com/golang/snappy package main import ( "bytes" "encoding/hex" "fmt" "io/ioutil" "log" "os" "github.com/golang/snappy" ) func main() { // read and decode the decompressed file plainhex, err := ioutil.readfile(os.args[1]) if err != nil { log.fatalf("failed to read decompressed file %s: %v", os.args[1], err) } plain, err := hex.decodestring(string(plainhex)) if err != nil { log.fatalf("failed to decode decompressed file: %v", err) } // read and decode the compressed file comphex, err := ioutil.readfile(os.args[2]) if err != nil { log.fatalf("failed to read compressed file %s: %v", os.args[2], err) } comp, err := hex.decodestring(string(comphex)) if err != nil { log.fatalf("failed to decode compressed file: %v", err) } // make sure they match decomp, err := snappy.decode(nil, comp) if err != nil { log.fatalf("failed to decompress compressed file: %v", err) } if !bytes.equal(plain, decomp) { fmt.println("booo, decompressed file does not match provided plain text!") return } fmt.println("yay, decompressed data matched provided plain text!") } $ go run main.go block.rlp block.go.snappy yay, decompressed data matched provided plain text! $ go run main.go block.rlp block.py.snappy yay, decompressed data matched provided plain text! python $ pip install python-snappy import snappy import sys # read and decode the decompressed file with open(sys.argv[1], 'rb') as file: plainhex = file.read() plain = plainhex.decode("hex") # read and decode the compressed file with open(sys.argv[2], 'rb') as file: comphex = file.read() comp = comphex.decode("hex") # make sure they match decomp = snappy.uncompress(comp) if plain != decomp: print "booo, decompressed file does not match provided plain text!" else: print "yay, decompressed data matched provided plain text!" $ python main.py block.rlp block.go.snappy yay, decompressed data matched provided plain text! $ python main.py block.rlp block.py.snappy yay, decompressed data matched provided plain text! references snappy website: https://google.github.io/snappy/ snappy specification: https://github.com/google/snappy/blob/master/format_description.txt copyright copyright and related rights waived via cc0. citation please cite this document as: péter szilágyi , "eip-706: devp2p snappy compression," ethereum improvement proposals, no. 706, september 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-706. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-173: contract ownership standard ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-173: contract ownership standard a standard interface for ownership of contracts authors nick mudge (@mudgen), dan finlay created 2018-06-07 table of contents abstract motivation specification rationale security considerations backwards compatibility copyright abstract this specification defines standard functions for owning or controlling a contract. an implementation allows reading the current owner (owner() returns (address)) and transferring ownership (transferownership(address newowner)) along with a standardized event for when ownership is changed (ownershiptransferred(address indexed previousowner, address indexed newowner)). motivation many smart contracts require that they be owned or controlled in some way. for example to withdraw funds or perform administrative actions. it is so common that the contract interface used to handle contract ownership should be standardized to allow compatibility with user interfaces and contracts that manage contracts. here are some examples of kinds of contracts and applications that can benefit from this standard: exchanges that buy/sell/auction ethereum contracts. this is only widely possible if there is a standard for getting the owner of a contract and transferring ownership. contract wallets that hold the ownership of contracts and that can transfer the ownership of contracts. contract registries. it makes sense for some registries to only allow the owners of contracts to add/remove their contracts. a standard must exist for these contract registries to verify that a contract is being submitted by the owner of it before accepting it. user interfaces that show and transfer ownership of contracts. specification every erc-173 compliant contract must implement the erc173 interface. contracts should also implement erc165 for the erc-173 interface. /// @title erc-173 contract ownership standard /// note: the erc-165 identifier for this interface is 0x7f5828d0 interface erc173 /* is erc165 */ { /// @dev this emits when ownership of a contract changes. event ownershiptransferred(address indexed previousowner, address indexed newowner); /// @notice get the address of the owner /// @return the address of the owner. function owner() view external returns(address); /// @notice set the address of the new owner of the contract /// @dev set _newowner to address(0) to renounce any ownership. /// @param _newowner the address of the new owner of the contract function transferownership(address _newowner) external; } interface erc165 { /// @notice query if a contract implements an interface /// @param interfaceid the interface identifier, as specified in erc-165 /// @dev interface identification is specified in erc-165. /// @return `true` if the contract implements `interfaceid` and /// `interfaceid` is not 0xffffffff, `false` otherwise function supportsinterface(bytes4 interfaceid) external view returns (bool); } the owner() function may be implemented as pure or view. the transferownership(address _newowner) function may be implemented as public or external. to renounce any ownership of a contract set _newowner to the zero address: transferownership(address(0)). if this is done then a contract is no longer owned by anybody. the ownershiptransferred event should be emitted when a contract is created. rationale key factors influencing the standard: keeping the number of functions in the interface to a minimum to prevent contract bloat. backwards compatibility with existing contracts. simplicity gas efficient several ownership schemes were considered. the scheme chosen in this standard was chosen because of its simplicity, low gas cost and backwards compatibility with existing contracts. here are other schemes that were considered: associating an ethereum name service (ens) domain name with a contract. a contract’s owner() function could look up the owner address of a particular ens name and use that as the owning address of the contract. using this scheme a contract could be transferred by transferring the ownership of the ens domain name to a different address. short comings to this approach are that it is not backwards compatible with existing contracts and requires gas to make external calls to ens related contracts to get the owner address. associating an erc721-based non-fungible token (nft) with a contract. ownership of a contract could be tied to the ownership of an nft. the benefit of this approach is that the existing erc721-based infrastructure could be used to sell/buy/auction contracts. short comings to this approach are additional complexity and infrastructure required. a contract could be associated with a particular nft but the nft would not track that it had ownership of a contract unless it was programmed to track contracts. in addition handling ownership of contracts this way is not backwards compatible. this standard does not exclude the above ownership schemes or other schemes from also being implemented in the same contract. for example a contract could implement this standard and also implement the other schemes so that ownership could be managed and transferred in multiple ways. this standard does provide a simple ownership scheme that is backwards compatible, is light-weight and simple to implement, and can be widely adopted and depended on. this standard can be (and has been) extended by other standards to add additional ownership functionality. security considerations if the address returned by owner() is an externally owned account then its private key must not be lost or compromised. backwards compatibility many existing contracts already implement this standard. copyright copyright and related rights waived via cc0. citation please cite this document as: nick mudge (@mudgen), dan finlay , "erc-173: contract ownership standard," ethereum improvement proposals, no. 173, june 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-173. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-4444: bound historical data in execution clients ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: networking eip-4444: bound historical data in execution clients prune historical data in clients older than one year authors george kadianakis (@asn-d6), lightclient (@lightclient), alex stokes (@ralexstokes) created 2021-11-02 discussion link https://ethereum-magicians.org/t/eip-4444-bound-historical-data-in-execution-clients/7450 table of contents abstract motivation specification rationale why a year? backwards compatibility preserving historical data full syncing from genesis user experience json-rpc changes security considerations relying on weak subjectivity centralization/censorship risk confusion with other proposals copyright abstract clients must stop serving historical headers, bodies, and receipts older than one year on the p2p layer. clients may locally prune this historical data. motivation historical blocks and receipts currently occupy more than 400gb of disk space (and growing!). therefore, to validate the chain, users must typically have a 1tb disk. historical data is not necessary for validating new blocks, so once a client has synced the tip of the chain, historical data is only retrieved when requested explicitly over the json-rpc or when a peer attempts to sync the chain. by pruning the history, this proposal reduces the disk requirements for users. pruning history also allows clients to remove code that processes historical blocks. this means that execution clients don’t need to maintain code paths that deal with each upgrade’s compounding changes. finally, this change will result in less bandwidth usage on the network as clients adopt more lightweight sync strategies based on the pos weak subjectivity assumption. specification parameter value description history_prune_epochs 82125 a year in beacon chain epochs clients should not serve headers, block bodies, and receipts that are older than history_prune_epochs epochs on the p2p network. clients may locally prune headers, block bodies, and receipts that is older than history_prune_epochs epochs. bootstrapping and syncing this eip impacts the way clients bootstrap and sync. clients will not be able to full sync using devp2p since historical data will no longer be served. clients must use a valid weak subjectivity checkpoint to bootstrap from a more recent view of the chain. for the purpose of syncing, clients treat weak subjectivity checkpoints as the genesis block. we call this method “checkpoint sync”. for the purposes of this proposal, we assume clients always start with a configured and valid weak subjectivity checkpoint. the way this is achieved is out-of-scope for this proposal. rationale this proposal forces clients to stop serving old historical data over p2p. we make this explicit to force clients to seek historical data from other sources, instead of relying on the optional behavior of some clients which would result in quality degradation. why a year? this proposal sets history_prune_epochs to 82125 epochs (one earth year). this constant is large enough to provide sufficient room for the weak subjectivity period to grow, and it’s also small enough so as to not occupy too much disk space. backwards compatibility preserving historical data this proposal impacts nodes that make use of historical data (e.g. web3 applications that display history of blocks, transactions or accounts). preserving the history of ethereum is fundamental and we believe there are various out-of-band ways to achieve this. historical data can be packaged and shared via torrent magnet links or over networks like ipfs. furthermore, systems like the portal network or the graph can be used to acquire historical data. clients should allow importing and exporting of historical data. clients can provide scripts that fetch/verify data and automatically import them. full syncing from genesis full syncing will no longer be possible over the p2p network. however, we do want to allow interested parties to do so on their own. we suggest that a specialized “full sync” client is built. the client is a shim that pieces together different releases of execution engines and can import historical blocks to validate the entire ethereum chain from genesis and generate all other historical data. it’s important to also note that although archive nodes with “state sync” functionality are in development, full sync is currently the only reliable way to bootstrap them. clients that wish to continue providing archive support would need the ability to import historical blocks retrieved out-of-band and retain support for each historical upgrade of the network. user experience this proposal impacts the ux for setting up applications that use historical data. hence we suggest that clients introduce this change in two phases: in the first phase, clients don’t prune historical data by default. they introduce a command line option similar to geth’s --txlookuplimit that users can use if they want to prune historical data. in the second phase, history is pruned by default and the command line option is removed. clients assume that users will find and import data in an out-of-band way. json-rpc changes after this proposal is implemented, certain json-rpc endpoints (e.g. like getblockbyhash) won’t be able to tell whether a given hash is invalid or just too old. other endpoints like getlogs will simply no longer have the data the user is requesting. the way this regression should be handled by applications or clients is out-of-scope for this proposal. security considerations relying on weak subjectivity with the move to pos, it’s essential for security to use valid weak subjectivity checkpoints because of long-range attacks. this proposal relies on the weak subjectivity assumption and assumes that clients will not bootstrap with an invalid or old ws checkpoint. this proposal also assumes that the weak subjectivity period will never be longer than history_prune_epochs. if that were to happen, clients with an old weak subjectivity checkpoint would never be able to “checkpoint sync” since the p2p network would not be able to provide the required data. centralization/censorship risk there are censorship/availability risks if there is a lack of incentives to keep historical data. it’s important that ethereum historical data are preserved and seeded by independent organizations, and their availability should be checked frequently. we consider these mechanisms as out-of-scope for this proposal. furthermore, there is a risk that more dapps will rely on centralized services for acquiring historical data because it will be harder to setup a full node. confusion with other proposals because there are a number of alternative proposals for reducing the execution client’s footprint on disk, we’ve decided to enforce a specific pronouncination of the eip. when pronouncing the eip number, it must be pronounced eip “four fours”. all other pronounciations are incorrect. copyright copyright and related rights waived via cc0. citation please cite this document as: george kadianakis (@asn-d6), lightclient (@lightclient), alex stokes (@ralexstokes), "eip-4444: bound historical data in execution clients [draft]," ethereum improvement proposals, no. 4444, november 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4444. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6357: single-contract multi-delegatecall ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: erc erc-6357: single-contract multi-delegatecall allows an eoa to call multiple functions of a smart contract in a single transaction authors gavin john (@pandapip1) created 2023-01-18 last call deadline 2023-11-10 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification rationale backwards compatibility test cases reference implementation security considerations copyright abstract this eip standardizes an interface containing a single function, multicall, allowing eoas to call multiple functions of a smart contract in a single transaction, and revert all calls if any call fails. motivation currently, in order to transfer several erc-721 nfts, one needs to submit a number of transactions equal to the number of nfts being tranferred. this wastes users’ funds by requiring them to pay 21000 gas fee for every nft they transfer. 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. contracts implementing this eip must implement the following interface: pragma solidity ^0.8.0; interface imulticall { /// @notice takes an array of abi-encoded call data, delegatecalls itself with each calldata, and returns the abi-encoded result /// @dev reverts if any delegatecall reverts /// @param data the abi-encoded data /// @returns results the abi-encoded return values function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results); /// @notice optional. takes an array of abi-encoded call data, delegatecalls itself with each calldata, and returns the abi-encoded result /// @dev reverts if any delegatecall reverts /// @param data the abi-encoded data /// @param values the effective msg.values. these must add up to at most msg.value /// @returns results the abi-encoded return values function multicallpayable(bytes[] calldata data, uint256[] values) external payable virtual returns (bytes[] memory results); } rationale multicallpayable is optional because it isn’t always feasible to implement, due to the msg.value splitting. backwards compatibility this is compatible with most existing multicall functions. test cases the following javascript code, using the ethers library, should atomically transfer amt units of an erc-20 token to both addressa and addressb. await token.multicall(await promise.all([ token.interface.encodefunctiondata('transfer', [ addressa, amt ]), token.interface.encodefunctiondata('transfer', [ addressb, amt ]), ])); reference implementation pragma solidity ^0.8.0; /// derived from openzeppelin's implementation abstract contract multicall is imulticall { function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) { results = new bytes[](data.length); for (uint256 i = 0; i < data.length; i++) { (bool success, bytes memory returndata) = address(this).delegatecall(data); require(success); results[i] = returndata; } return results; } } security considerations multicallpayable should only be used if the contract is able to support it. a naive attempt at implementing it could allow an attacker to call a payable function multiple times with the same ether. copyright copyright and related rights waived via cc0. citation please cite this document as: gavin john (@pandapip1), "erc-6357: single-contract multi-delegatecall [draft]," ethereum improvement proposals, no. 6357, january 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6357. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. on slow and fast block times | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search on slow and fast block times posted by vitalik buterin on september 14, 2015 research & development one of the largest sources of confusion in the question of blockchain security is the precise effect of the block time. if one blockchain has a block time of 10 minutes, and the other has an estimated block time of 17 seconds, then what exactly does that mean? what is the equivalent of six confirmations on the 10-minute blockchain on the 17-second blockchain? is blockchain security simply a matter of time, is it a matter of blocks, or a combination of both? what security properties do more complex schemes have? note: this article will not go into depth on the centralization risks associated with fast block times; centralization risks are a major concern, and are the primary reason not to push block times all the way down to 1 second despite the benefits, and are discussed at much more length in this previous article; the purpose of this article is to explain why fast block times are desirable at all. the answer in fact depends crucially on the security model that we are using; that is, what are the properties of the attackers that we are assuming exist? are they rational, byzantine, economically bounded, computationally bounded, able to bribe ordinary users or not? in general, blockchain security analysis uses one of three different security models: normal-case model: there are no attackers. either everyone is altruistic, or everyone is rational but acts in an uncoordinated way. byzantine fault tolerance model: a certain percentage of all miners are attackers, and the rest are honest altruistic people. economic model: there is an attacker with a budget of $x which the attacker can spend to either purchase their own hardware or bribe other users, who are rational. reality is a mix between the three; however, we can glean many insights by examining the three models separately and seeing what happens in each one. the normal case let us first start off by looking at the normal case. here, there are no attackers, and all miners simply want to happily sing together and get along while they continue progressively extending the blockchain. now, the question we want to answer is this: suppose that someone sent a transaction, and k seconds have elapsed. then, this person sends a double-spend transaction trying to revert their original transaction (eg. if the original transaction sent $50000 to you, the double-spend spends the same $50000 but directs it into another account owned by the attacker). what is the probability that the original transaction, and not the double-spend, will end up in the final blockchain? note that, if all miners are genuinely nice and altruistic, they will not accept any double-spends that come after the original transaction, and so the probability should approach 100% after a few seconds, regardless of block time. one way to relax the model is to assume a small percentage of attackers; if the block time is extremely long, then the probability that a transaction will be finalized can never exceed 1-x, where x is the percentage of attackers, before a block gets created. we will cover this in the next section. another approach is to relax the altruism assumption and instead discuss uncoordinated rationality; in this case, an attacker trying to double-spend can bribe miners to include their double-spend transaction by placing a higher fee on it (this is essentially peter todd's replace-by-fee). hence, once the attacker broadcasts their double-spend, it will be accepted in any newly created block, except for blocks in chains where the original transaction was already included. we can incorporate this assumption into our question by making it slightly more complex: what is the probability that the original transaction has been placed in a block that will end up as part of the final blockchain? the first step to getting to that state is getting included in a block in the first place. the probability that this will take place after k seconds is pretty well established: unfortunately, getting into one block is not the end of the story. perhaps, when that block is created, another block is created at the same time (or, more precisely, within network latency); at that point, we can assume as a first approximation that it is a 50:50 chance which of those two blocks the next block will be built on, and that block will ultimately "win" or, perhaps, two blocks will be created once again at the same time, and the contest will repeat itself. even after two blocks have been created, it's possible that some miner has not yet seen both blocks, and that miner gets lucky and created three blocks one after the other. the possibilities are likely mathematically intractable, so we will just take the lazy shortcut and simulate them: script here the results can be understood mathematically. at 17 seconds (ie. 100% of the block time), the faster blockchain gives a probability of ~0.56: slightly smaller than the matheatically predicted 1-1/e ~= 0.632 because of the possibility of two blocks being created at the same time and one being discarded; at 600 seconds, the slower blockchain gives a probability of 0.629, only slightly smaller than the predicted 0.632 because with 10-minute blocks the probability of two blocks being created at the same time is very small. hence, we can see that faster blockchains do have a slight disadvantage because of the higher influence of network latency, but if we do a fair comparison (ie. waiting a particular number of seconds), the probability of non-reversion of the original transaction on the faster blockchain is much greater. attackers now, let's add some attackers into the picture. suppose that portion x of the network is taken up by attackers, and the remaining 1-x is made up of either altruistic or selfish but uncoordinated (barring selfish mining considerations, up to x it actually does not matter which) miners. the simplest mathematical model to use to approximate this is the weighted random walk. we start off assuming that a transaction has been confirmed for k blocks, and that the attacker, who is also a miner, now tries to start a fork of the blockchain. from there, we represent the situation with a score of k, meaning that the attacker's blockchain is k blocks behind the original chain, and at every step make the observation that there is a probability of x that the attacker will make the next block, changing the score to k-1 and a probability of 1-x that honest miners mining on the original chain will make the next block, changing the score to k+1. if we get to k = 0, that means that the original chain and the attacker's chain have the same length, and so the attacker wins. mathematically, we know that the probability of the attacker winning such a game (assuming x < 0.5 as otherwise the attacker can overwhelm the network no matter what the blockchain parameters are) is: we can combine this with a probability estimate for k (using the poisson distribution) and get the net probability of the attacker winning after a given number of seconds: script here note that for fast block times, we do have to make an adjustment because the stale rates are higher, and we do this in the above graph: we set x = 0.25 for the 600s blockchain and x = 0.28 for the 17s blockchain. hence, the faster blockchain does allow the probability of non-reversion to reach 1 much faster. one other argument that may be raised is that the reduced cost of attacking a blockchain for a short amount of time over a long amount of time means that attacks against fast blockchains may happen more frequently; however, this only slightly mitigates fast blockchains' advantage. for example, if attacks happen 10x more often, then this means that we need to be comfortable with, for example, a 99.99% probability of non-reversion, if before we were comfortable with a 99.9% probability of non-reversion. however, the probability of non-reversion approaches 1 exponentially, and so only a small number of extra confirmations (to be precise, around two to five) on the faster chain is required to bridge the gap; hence, the 17-second blockchain will likely require ten confirmations (~three minutes) to achieve a similar degree of security under this probabilistic model to six confirmations (~one hour) on the ten-minute blockchain. economically bounded attackers we can also approach the subject of attackers from the other side: the attacker has $x to spend, and can spend it on bribes, near-infinite instantaneous hashpower, or anything else. how high is the requisite x to revert a transaction after k seconds? essentially, this question is equivalent to "how much economic expenditure does it take to revert the number of blocks that will have been produced on top of a transaction after k seconds". from an expected-value point of view, the answer is simple (assuming a block reward of 1 coin per second in both cases): if we take into account stale rates, the picture actually turns slightly in favor of the longer block time: but "what is the expected economic security margin after k seconds" (using "expected" here in the formal probability-theoretic sense where it roughly means "average") is actually not the question that most people are asking. instead, the problem that concerns ordinary users is arguably one of them wanting to get "enough" security margin, and wanting to get there as quickly as possible. for example, if i am using the blockchain to purchase a $2 coffee, then a security margin of $0.03 (the current bitcoin transaction fee, which an attacker would need to outbid in a replace-by-fee model) is clearly not enough, but a security margin of $5 is clearly enough (ie. very few attacks would happen that spend $5 to steal $2 from you), and a security margin of $50000 is not much better. now, let us take this strict binary enough/not-enough model and apply it to a case where the payment is so small that one block reward on the faster blockchain is greater than the cost. the probability that we will have "enough" security margin after a given number of seconds is exactly equivalent to a chart that we already saw earlier: now, let us suppose that the desired security margin is worth between four and five times the smaller block reward; here, on the smaller chain we need to compute the probability that after k seconds at least five blocks will have been produced, which we can do via the poisson distribution: now, let us suppose that the desired security margin is worth as much as the larger block reward: here, we can see that fast blocks no longer provide an unambiguous benefit; in the short term they actually hurt your chances of getting more security, though that is compensated by better performance in the long term. however, what they do provide is more predictability; rather than a long exponential curve of possible times at which you will get enough security, with fast blocks it is pretty much certain that you will get what you need within 7 to 14 minutes. now, let us keep increasing the desired security margin further: as you can see, as the desired security margin gets very high, it no longer really matters that much. however, at those levels, you have to wait a day for the desired security margin to be achieved in any case, and that is a length of time that most blockchain users in practice do not end up waiting; hence, we can conclude that either (i) the economic model of security is not the one that is dominant, at least at the margin, or (ii) most transactions are small to medium sized, and so actually do benefit from the greater predictability of small block times. we should also mention the possibility of reverts due to unforeseen exigencies; for example, a blockchain fork. however, in these cases too, the "six confirmations" used by most sites is not enough, and waiting a day is required in order to be truly safe. the conclusion of all this is simple: faster block times are good because they provide more granularity of information. in the bft security models, this granularity ensures that the system can more quickly converge on the "correct" fork over an incorrect fork, and in an economic security model this means that the system can more quickly give notification to users of when an acceptable security margin has been reached. of course, faster block times do have their costs; stale rates are perhaps the largest, and it is of course necessary to balance the two a balance which will require ongoing research, and perhaps even novel approaches to solving centralization problems arising from networking lag. some developers may have the opinion that the user convenience provided by faster block times is not worth the risks to centralization, and the point at which this becomes a problem differs for different people, and can be pushed closer toward zero by introducing novel mechanisms. what i am hoping to disprove here is simply the claim, repeated by some, that fast block times provide no benefit whatsoever because if each block is fifty times faster then each block is fifty times less secure. appendix: eyal and sirer's bitcoin ng a recent interesting proposal presented at the scaling bitcoin conference in montreal is the idea of splitting blocks into two types: (i) infrequent (eg. 10 minute heartbeat) "key blocks" which select the "leader" that creates the next blocks that contain transactions, and (ii) frequent (eg. 10 second heartbeat) "microblocks" which contain transactions: the theory is that we can get very fast blocks without the centralization risks by essentially electing a dictator only once every (on average) ten minutes, for those ten minutes, and allowing the dictator to produce blocks very quickly. a dictator "should" produce blocks once every ten seconds, and in the case that the dictator attempts to double-spend their own blocks and create a longer new set of microblocks, a slasher-style algorithm is used where the dictator can be punished if they get caught: this is certainly an improvement over plain old ten-minute blocks. however, it is not nearly as effective as simply having regular blocks come once every ten seconds. the reasoning is simple. under the economically-bounded attacker model, it actually does offer the same probabilities of assurances as the ten-second model. under the bft model, however, it fails: if an attacker has 10% hashpower then the probability that a transaction will be final cannot exceed 90% until at least two key blocks are created. in reality, which can be modeled as a hybrid between the economic and bft scenarios, we can say that even though 10-second microblocks and 10-second real blocks have the same security margin, in the 10-second microblock case "collusion" is easier as within the 10-minute margin only one party needs to participate in the attack. one possible improvement to the algorithm may be to have microblock creators rotate during each inter-key-block phase, taking from the creators of the last 100 key blocks, but taking this approach to its logical conclusion will likely lead to reinventing full-on slasher-style proof of stake, albeit with a proof of work issuance model attached. however, the general approach of segregating leader election and transaction processing does have one major benefit: it reduces centralization risks due to slow block propagation (as key block propagation time does not depend on the size of the content-carrying block), and thus substantially increases the maximum safe transaction throughput (even beyond the margin provided through ethereum-esque uncle mechanisms), and for this reason further research on such schemes should certainly be done. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-7528: eth (native asset) address convention ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: erc erc-7528: eth (native asset) address convention an address placeholder for eth when used in the same context as an erc-20 token. authors joey santoro (@joeysantoro) created 2023-10-03 requires eip-20, eip-155, eip-4626 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification rationale considered alternative addresses backwards compatibility security considerations copyright abstract the following standard proposes a convention for using the address 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee in all contexts where an address is used to represent eth in the same capacity as an erc-20 token. this would apply to both events where an address field would denote eth or an erc-20 token, as well as discriminators such as the asset field of an erc-4626 vault. this standard generalizes to other evm chains where the native asset is not eth. motivation eth, being a fungible unit of value, often behaves similarly to erc-20 tokens. protocols tend to implement a standard interface for erc-20 tokens, and benefit from having the eth implementation to closely mirror the erc-20 implementations. in many cases, protocols opt to use wrapped eth (e.g. weth9 deployed at address 0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2 on etherum mainnet) for erc-20 compliance. in other cases, protocols will use native eth due to gas considerations, or the requirement of using native eth such as in the case of a liquid staking token (lst). in addition, protocols might create separate events for handling eth native cases and erc-20 cases. this creates data fragmentation and integration overhead for off-chain infrastructure. by having a strong convention for an eth address to use for cases where it behaves like an erc-20 token, it becomes beneficial to use one single event format for both cases. one intended use case for the standard is erc-4626 compliant lsts which use eth as the asset. this extends the benefits and tooling of erc-4626 to lsts and integrating protocols. this standard allows protocols and off-chain data infrastructure to coordinate around a shared understanding that any time 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee is used as an address in an erc-20 context, it means eth. specification this standard applies for all components of smart contract systems in which an address is used to identify an erc-20 token, and where native eth is used in certain instances in place of an erc-20 token. the usage of the term token below means eth or an erc-20 in this context. any fields or events where an erc-20 address is used, yet the underlying token is eth, the address field must return 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee any fields or events where the token is a non-enshrined wrapped erc-20 version of eth (i.e weth9) must use that token’s address and must not use 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee. where appropriate, the address should be checksummed. e.g. the eip-155 checksum is 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee. rationale considered alternative addresses many existing implementations of the same use case as this standard use addresses such as 0x0, 0x1, and 0xe for gas efficiency of having leading zero bytes. ultimately, all of these addresses collide with potential precompile addresses and are less distinctive as identifiers for eth. 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee has the most current usage, is distinctive, and would not collide with any precompiles. these benefits outweigh the potential gas benefits of other alternatives. backwards compatibility this standard has no known compatibility issues with other standards. security considerations using eth as a token instead of weth exposes smart contract systems to re-entrancy and similar classes of vulnerabilities. implementers must take care to follow the industry standard development patterns (e.g. checks-effects-interactions) when the token is eth. copyright copyright and related rights waived via cc0. citation please cite this document as: joey santoro (@joeysantoro), "erc-7528: eth (native asset) address convention [draft]," ethereum improvement proposals, no. 7528, october 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7528. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2584: trie format transition with overlay trees ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-2584: trie format transition with overlay trees authors guillaume ballet (@gballet) created 2020-04-03 discussion link https://ethresear.ch/t/overlay-method-for-hex-bin-tree-conversion/7104 table of contents simple summary abstract motivation specification binary tries phase 1 phase 2 phase 3 rationale backwards compatibility test cases implementation security considerations community feedback copyright simple summary this eip proposes a method to convert the state trie format from hexary to binary: new values are directly stored in a binary trie “laid over” the hexary trie. meanwhile, the hexary trie is converted to a binary trie in the background. when the process is finished, both layers are merged. abstract this eip describes a four phase process to complete the conversion. in the first phase, all new state writes are made to an overlay binary trie, while the hexary trie is being converted to binary. the block format is changed to have two storage roots: the root of the hexary trie (hereafter called the “base” trie) and the root of the overlay binary trie. after enough time has been given to miners to perform the conversion, the second phase begins. the overlay tree is progressively merged back into the newly converted binary base trie. a constant number of entries are deleted from the overlay and inserted into the base trie. the third and final phase begins when the overlay trie is empty. the field holding its root is removed from the block header. motivation there is a long running interest in switching the state trie from a hexary format to a binary format, for reasons pertaining to proof and storage sizes. the conversion process poses a catch-up issue, caused by the sheer size of the full state: it can not be translated in a reasonable time (i.e. on the same order of magnitude as the block time). specification this specification follows the notation introduced by the yellow paper. prior to reading it is advisable to be familiar with the yellow paper. binary tries this eip assumes that a binary trie is defined like the mpt, except that: the series of bytes in i₀ is seen as a series of bits and so ∀i≤256, i₀[i] is the ith bit in key i₀ the first item of an extension or a leaf is replacing nibbles with bits; a branch is a 2 item structure in which both items correspond to each of the two possible bit values for the keys at this point in their traversal; c(𝕴,i) ≡ rlp((u(0), u(1)) at a branch, where u(j) = n({i : i ∈ 𝕴 ⋀ i₀[i] = j}, i+1) let ß be the function that, given a hexary trie, computes the equivalent representation of that trie in the aforementioned binary trie format. phase 1 let h₁ be the previously agreed-upon block height at which phase 1 starts, and h₂ the block at which phase 2 starts. for each block of height h₁ ≤ h < h₂: a conversion process is started in the background, to turn the hexary trie into its binary equivalent. the end goal of this process is the calculation of the root hash of the converted binary trie, denoted hᵣ². the root of the hexary trie is hereafter called hᵣ¹⁶. formally, this process is written as hᵣ² ≡ ß(hᵣ¹⁶). block headers contain a new hₒ field, which is the root of the overlay binary trie; hᵣ ≡ p(h)ᵣ¹⁶, i.e. as long as the conversion from hexary to binary is not complete, the hexary trie root is the same as that of its parent block. the following is changed in the execution environment: upon executing a state read, ϒ first searches for the address in the overlay trie. if the key can not be found there, ϒ then searches the base trie as it did at block heights h’ < h₁; upon executing a state write, ϒ inserts or updates the value into the overlay tree. the base tree is left untouched; if an account is deleted, ϒ inserts the empty hash h(∅) at the address of that account in order to mark its deletion; reads from such an address behave the same as a missing account, regardless of what is present in the base trie. phase 1 ends at block height h₂, which is set far enough from h₁ to offer miners enough time to perform the conversion. phase 2 this phase differs from the previous one on the following points: at block height h₂, before the execution of ϒ, hᵣ ≡ hᵣ², i.e. the value before the execution of the transition function is set to the root of the converted binary base trie; hₒ is still present in the block tree, however the overlay trie content can only be read from or deleted; at block height h ≥ h₂, before the execution of ϒ, n accounts are being deleted from the binary overlay trie and inserted into the binary base trie; upon executing a state write, ϒ will insert or update the value into the base trie. if the search key exists in the overlay trie, it is deleted. account deletion is performed according to the following rules: the first n accounts (in lexicographic order) remaining in the overlay tree are selected; for each of these accounts: if the value is the empty hash, remove the account at the same address from the binary base trie; otherwise, insert/update the account at the corresponding address in the base trie with its overlay trie value. when the overlay trie is empty, phase 2 ends and phase 3 begins. phase 3 phase 3 is the same as phase 2, except for the following change: hₒ is dropped from the block header rationale methods that have been discussed until now include a “stop the world” approach, in which the chain is stopped for the significant amount of time that is required by the conversion, and a “copy on write” approach, in which branches are converted upon being accessed. the approach suggested here has the advantage that the chain continues to operate normally during the conversion process, and that the tree is fully converted to a binary format, in a predictable time. backwards compatibility this requires a fork and will break backwards compatibility, as the hashes and block formats will necessarily be different. this will cause a fork in clients that don’t implement the overlay tree, and those that do not accept the new binary root. no mitigation is proposed, as this is a hard fork. test cases for testing phase 1, it suffices to check that every key in the hexary trie is also available in the binary trie. a looser but faster test picks 1% of keys in the hexary trie at random, and checks that they are present in the binary trie; tbd for phase 2 & 3 implementation a prototype version of the conversion process (phase 1) is available for geth in this pr. security considerations there are three attack vectors that i can foresee: a targeted attack that would cause the overlay trie to be unreasonably large. since gas costs will likely increase during the transition process, lengthening phase 2 will make ethereum more expensive during an extended period of time. this could be solved by increasing the cost of sstore during phase 1. conversely, if h₂ comes too soon, a majority of miners might not be able to produce the correct value for hᵣ² in time. if a group of miners representing more than 51% of the network are reporting an invalid value, they could be stealing funds without anyone having a say. community feedback preliminary tests indicate that a fast machine can perform the conversion in roughly 30 minutes. the initial version of this eip expected miners to vote on the value of the binary base root. this has been removed because of the complexity of this process, and because this functionality is already guaranteed by the “longest chain” rule. copyright copyright and related rights waived via cc0. citation please cite this document as: guillaume ballet (@gballet), "eip-2584: trie format transition with overlay trees [draft]," ethereum improvement proposals, no. 2584, april 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2584. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-7002: execution layer triggerable exits ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: core eip-7002: execution layer triggerable exits allows validators to trigger exits via their execution layer (0x01) withdrawal credentials authors danny ryan (@djrtwo), mikhail kalinin (@mkalinin), ansgar dietrichs (@adietrichs), hsiao-wei wang (@hwwhww) created 2023-05-09 discussion link https://ethereum-magicians.org/t/eip-7002-execution-layer-triggerable-exits/14195 table of contents abstract motivation specification constants configuration execution layer consensus layer rationale stateful precompile validator_pubkey field exit message queue utilizing call to return excess payment rate limiting using exit fee target_exits_per_block configuration value exit fee update rule exits inside of the block backwards compatibility security considerations impact on existing custody relationships copyright abstract adds a new stateful precompile that allows validators to trigger exits to the beacon chain from their execution layer (0x01) withdrawal credentials. these new execution layer exit messages are appended to the execution layer block to reading by the consensus layer. motivation validators have two keys – an active key and a withdrawal credential. the active key takes the form of a bls key, whereas the withdrawal credential can either be a bls key (0x00) or an execution layer address (0x01). the active key is “hot”, actively signing and performing validator duties, whereas the withdrawal credential can remain “cold”, only performing limited operations in relation to withdrawing and ownership of the staked eth. due to this security relationship, the withdrawal credential ultimately is the key that owns the staked eth and any rewards. as currently specified, only the active key can initiate a validator exit. this means that in any non-standard custody relationships (i.e. active key is separate entity from withdrawal credentials), that the ultimate owner of the funds – the possessor of the withdrawal credentials – cannot independently choose to exit and begin the withdrawal process. this leads to either trust issues (e.g. eth can be “held hostage” by the active key owner) or insufficient work-arounds such as pre-signed exits. additionally, in the event that active keys are lost, a user should still be able to recover their funds by using their cold withdrawal credentials. to ensure that the withdrawal credentials (owned by both eoas and smart contracts) can trustlessly control the destiny of the staked eth, this specification enables exits triggerable by 0x01 withdrawal credentials. note, 0x00 withdrawal credentials can be changed into 0x01 withdrawal credentials with a one-time signed message. thus any functionality enabled for 0x01 credentials is defacto enabled for 0x00 credentials. specification constants name value comment fork_timestamp tbd mainnet configuration name value comment validator_exit_precompile_address tbd where to call and store relevant details about exit mechanism excess_exits_storage_slot 0 exit_count_storage_slot 1 exit_message_queue_head_storage_slot 2 pointer to head of the exit message queue exit_message_queue_tail_storage_slot 3 pointer to the tail of the exit message queue exit_message_queue_storage_offset 4 the start memory slot of the in-state exit message queue max_exits_per_block 16 maximum number of exits that can be dequeued into a block target_exits_per_block 2 min_exit_fee 1 exit_fee_update_fraction 17 excess_return_gas_stipend 2300 execution layer definitions fork_block – the first block in a blockchain with the timestamp greater or equal to fork_timestamp. exit operation the new exit operation consists of the following fields: source_address: bytes20 validator_pubkey: bytes48 rlp encoding of an exit must be computed as the following: rlp_encoded_exit = rlp([ source_address, validator_pubkey, ]) validator exit precompile the precompile requires a single 48 byte input, aliased to validator_pubkey. calls to validator_exit_precompile_address perform the following: ensure enough eth was sent to cover the current exit fee (check_exit_fee()) increase exit count by 1 for the current block (increment_exit_count()) insert an exit into the queue for the source address and validator pubkey (insert_exit_to_queue()) return any unspent eth in excess of the exit fee with an excess_return_gas_stipend gas stipend (return_excess_payment()) specifically, the functionality is defined in pseudocode as the function trigger_exit(): ################### # public function # ################### def trigger_exit(bytes48: validator_pubkey): check_exit_fee(msg.value) increment_exit_count() insert_exit_to_queue(msg.sender, validator_pubkey) return_excess_payment(msg.value) ################### # primary helpers # ################### def check_exit_fee(int: fee_sent): exit_fee = get_exit_fee() require(fee_sent >= exit_fee, 'insufficient exit fee') # note: consider mapping `min_exit_fee` -> 0 fee def insert_exit_to_queue(address: source_address, bytes48: validator_pubkey): queue_tail_index = sload(validator_exit_precompile_address, exit_message_queue_tail_storage_slot) # each exit takes 3 storage slots: 1 for source_address, 2 for validator_pubkey queue_storage_slot = exit_message_queue_storage_offset + queue_tail_index * 3 sstore(validator_exit_precompile_address, queue_storage_slot, source_address) sstore(validator_exit_precompile_address, queue_storage_slot + 1, validator_pubkey[0:32]) sstore(validator_exit_precompile_address, queue_storage_slot + 2, validator_pubkey[32:48]) sstore(validator_exit_precompile_address, exit_message_queue_tail_storage_slot, queue_tail_index + 1) def increment_exit_count(): exit_count = sload(validator_exit_precompile_address, exit_count_storage_slot) sstore(validator_exit_precompile_address, exit_count_storage_slot, exit_count + 1) def return_excess_payment(int: fee_sent, address: source_address): excess_payment = fee_sent get_exit_fee() if excess_payment > 0: (bool sent, bytes memory data) = source_address.call{value: excess_payment, gas: excess_return_gas_stipend}("") require(sent, "failed to return excess fee payment") ###################### # additional helpers # ###################### def get_exit_fee() -> int: excess_exits = sload(validator_exit_precompile_address, excess_exits_storage_slot) return fake_exponential( min_exit_fee, excess_exits, exit_fee_update_fraction ) def fake_exponential(factor: int, numerator: int, denominator: int) -> int: i = 1 output = 0 numerator_accum = factor * denominator while numerator_accum > 0: output += numerator_accum numerator_accum = (numerator_accum * numerator) // (denominator * i) i += 1 return output // denominator gas cost tbd once functionality is reviewed and solidified, we’ll estimate the cost of running the above computations fully in the evm, and then potentially apply some discount due to reduced evm overhead of being able to execute the above logic natively. block structure beginning with the fork_block, the block body must be appended with a list of exit operations. rlp encoding of the extended block body structure must be computed as follows: block_body_rlp = rlp([ field_0, ..., # latest block body field before `exits` field_n, [exit_0, ..., exit_k], ]) beginning with the fork_block, the block header must be appended with the new exits_root field. the value of this field is the trie root committing to the list of exits in the block body. exits_root field value must be computed as follows: def compute_trie_root_from_indexed_data(data): trie = trie.from([(i, obj) for i, obj in enumerate(data)]) return trie.root block.header.exits_root = compute_trie_root_from_indexed_data(block.body.exits) block validity beginning with the fork_block, client software must extend block validity rule set with the following conditions: value of exits_root block header field equals to the trie root committing to the list of exit operations contained in the block. to illustrate: def compute_trie_root_from_indexed_data(data): trie = trie.from([(i, obj) for i, obj in enumerate(data)]) return trie.root assert block.header.exits_root == compute_trie_root_from_indexed_data(block.body.exits) the list of exit operations contained in the block body must be equivalent to list of exits at the head of the exit precompile’s exit message queue up to the maximum of max_exits_per_block, respecting the order in the queue. this validation must be run after all transactions in the current block are processed and must be run before per-block precompile storage calculations (i.e. a call to update_exit_precompile()) are performed. to illustrate: class validatorexit(object): source_address: bytes20 validator_pubkey: bytes48 queue_head_index = sload(validator_exit_precompile_address, exit_message_queue_head_storage_slot) queue_tail_index = sload(validator_exit_precompile_address, exit_message_queue_tail_storage_slot) num_exits_in_queue = queue_tail_index queue_head_index num_exits_to_dequeue = min(num_exits_in_queue, max_exits_per_block) # retrieve exits from the queue expected_exits = [] for i in range(num_exits_to_dequeue): queue_storage_slot = exit_message_queue_storage_offset + (queue_head_index + i) * 3 source_address = address(sload(validator_exit_precompile_address, queue_storage_slot)[0:20]) validator_pubkey = ( sload(validator_exit_precompile_address, queue_storage_slot + 1)[0:32] + sload(validator_exit_precompile_address, queue_storage_slot + 2)[0:16] ) exit = validatorexit( source_address=bytes20(source_address), validator_pubkey=bytes48(validator_pubkey), ) expected_exits.append(exit) # compare retrieved exits to the list in the block body assert block.body.exits == expected_exits a block that does not satisfy the above conditions must be deemed invalid. block processing per-block precompile storage calculations at the end of processing any execution block where block.timestamp >= fork_timestamp (i.e. after processing all transactions and after performing the block body exit validations): the exit precompile’s exit queue is updated based on exits dequeued and the exit queue head/tail are reset if the queue has been cleared (update_exit_queue()) the exit precompile’s excess exits are updated based on usage in the current block (update_excess_exits()) the exit precompile’s exit count is reset to 0 (reset_exit_count()) specifically, the functionality is defined in pseudocode as the function update_exit_precompile(): ################### # public function # ################### def update_exit_precompile(): update_exit_queue() update_excess_exits() reset_exit_count() ########### # helpers # ########### def update_exit_queue(): queue_head_index = sload(validator_exit_precompile_address, exit_message_queue_head_storage_slot) queue_tail_index = sload(validator_exit_precompile_address, exit_message_queue_tail_storage_slot) num_exits_in_queue = queue_tail_index queue_head_index num_exits_dequeued = min(num_exits_in_queue, max_exits_per_block) new_queue_head_index = queue_head_index + num_exits_dequeued if new_queue_head_index == queue_tail_index: # queue is empty, reset queue pointers sstore(validator_exit_precompile_address, exit_message_queue_head_storage_slot, 0) sstore(validator_exit_precompile_address, exit_message_queue_tail_storage_slot, 0) else: sstore(validator_exit_precompile_address, exit_message_queue_head_storage_slot, new_queue_head_index) def update_excess_exits(): previous_excess_exits = sload(validator_exit_precompile_address, excess_exits_storage_slot) exit_count = sload(validator_exit_precompile_address, exit_count_storage_slot) new_excess_exits = 0 if previous_excess_exits + exit_count > target_exits_per_block: new_excess_exits = previous_excess_exits + exit_count target_exits_per_block sstore(validator_exit_precompile_address, excess_exits_storage_slot, new_excess_exits) def reset_exit_count(): sstore(validator_exit_precompile_address, exit_count_storage_slot, 0) consensus layer sketch of spec: new operation executionlayerexit will show up in executionpayload as an ssz list bound by length max_exits_per_block new function in process_execution_layer_exit that has similar functionality to process_voluntary_exit but that can fail validations (e.g. validator is already exited) without the block failing (similar to deposit coming from el) process_execution_layer_exit called in process_operations for each executionlayerexit found in the executionpayload rationale stateful precompile this specification utilizes a stateful precompile for simplicity and future-proofness. while precompiles are a well-known quantity, none to date have associated evm state at the address. the alternative designs are (1) to utilize a precompile or opcode for the functionality and write a separate specified space in the evm – e.g. 0xff..ff – or (2) to place the required state into the block and require the previous block header as an input into the state transition function (e.g. like eip-1559 base_fee). alternative design (1) is essentially using a stateful precompile but dissociating the state into a separate address. at first glance, this split appears unnecessarily convoluted when we could store the location of the call and the associated state in the same address. that said, there might be unexpected engineering constraints around precompiles in existing clients that make this a preferable path. alternative design (2) has two main drawbacks. the first is that with the message queue contains an unbounded amount of state (as opposed to simple the base_fee in the similar eip-1559 design). additionally, even if the state was constrained to a single variable or two, this design pattern reinforces that the ethereum state transition function signature be more than f(pre_state, block) -> post_state by putting another dependency on the pre_block_header. these additional dependencies hinder the elegance of future stateless designs. providing these dependencies within the evm state as specified, allows for them to show up naturally in block witnesses. validator_pubkey field multiple validators can utilize the same execution layer withdrawal credential, thus the validator_pubkey field is utilized to disambiguate which validator is being exited. note, validator_index also disambiguates validators but is not used because the execution-layer cannot currently trustlessly ascertain this value. exit message queue the exit precompile maintains and in-state queue of exit messages to be dequeued each block into the block and thus into the execution layer. the number of exits that can be passed into the consensus layer are bound by max_exits_per_block to bound the load both on the block size as well as on the consensus layer processing. 16 has been chosen for max_exits_per_block to be in line with the bounds of similar operations on the beacon chain – e.g. voluntaryexit and deposit. although there is a maximum number of exits that can passed to the consensus layer each block, the execution layer gas limit can provide for far more calls to the exit precompile at each block. the queue then allows for these calls to successfully be made while still maintaining a system rate limit. the alternative design considered was to have calls to the exit precompile fail after max_exits_per_block successful calls were made within the context of a single block. this would eliminate the need for the message queue, but would come at the cost of a bad ux of precompile call failures in times of high exiting. the complexity to mitigate this bad ux is relatively low and is currently favored. utilizing call to return excess payment calls to the exit precompile require a fee payment defined by the current state of the precompile. smart contracts can easily perform a read/calculation to pay the precise fee, whereas eoas will likely need to compute and send some amount over the current fee at time of signing the transaction. this will result in eoas having fee payment overages in the normal case. these should be returned to the caller. there are two potential designs to return excess fee payments to the caller (1) use an evm call with some gas stipend or (2) have special functionality to allow the precompile to “credit” the caller’s account with the excess fee. option (1) has been selected in the current specification because it utilizes less exceptional functionality and is likely simpler to implement and ensure correctness. the current version sends a gas stipen of 2300. this is following the (outdated) solidity pattern primarily to simplify precompile gas accounting (allowing it to be a fixed instead of dynamic cost). the call could forward the maximum allowed gas but would then require the cost of the precompile to be dynamic. option (2) utilizes custom logic (exceptional to base evm logic) to credit the excess back to the callers balance. this would potentially simplify concerns around precompile gas costs/metering, but at the cost of non-standard evm complexity. we are open to this path, but want to solicit more input before writing it into the speficiation. rate limiting using exit fee transactions are naturally rate-limited in the execution layer via the gas limit, but an adversary willing to pay market-rate gas fees (and potentially utilize builder markets to pay for front-of-block transaction inclusion) can fill up the exit operation limits for relatively cheap, thus griefing honest validators that want to exit. there are two general approaches to combat this griefing – (a) only allow validators to send such messages and with a limit per time period or (b) utilize an economic method to make such griefing increasingly costly. method (a) (not used in this eip) would require eip-4788 (the beacon_root opcode) against which to prove withdrawal credentials in relation to validator pubkeys as well as a data-structure to track exits per-unit-time (e.g. 4 months) to ensure that a validator cannot grief the mechanism by submitting many exits. the downsides of this method are that it requires another cross-layer eip and that it is of higher cross-layer complexity (e.g. care that might need to be taken in future upgrades if, for example, the shape of the merkle tree of beacon_root changes, then the exit precompile and proof structure might need to be updated). method (b) has been utilized in this eip to eliminate additional eip requirements and to reduce cross-layer complexity to allow for correctness of this eip (now and in the future) to be easier to analyze. the eip-1559-style mechanism with a dynamically adjusting fee mechanism allows for users to pay min_exit_fee for exits in the normal case (fewer than 2 per block on average), but scales the fee up exponentially in response to high usage (i.e. potential abuse). target_exits_per_block configuration value target_exits_per_block has been selected as 2 such that even if all eth is staked (~120m eth -> 3.75m validators), the 64 validator per epoch target (2 * 32 slots) still exceeds the per-epoch exit churn limit on the consensus layer (defined by get_validator_churn_limit()) at such values – 57 validators per epoch (3.75m // 65536). exit fee update rule the exit fee update rule is intended to approximate the formula exit_fee = min_exit_fee * e**(excess_exits / exit_fee_update_fraction), where excess_exits is the total “extra” amount of exits that the chain has processed relative to the “targeted” number (target_exits_per_block per block). like eip-1559, it’s a self-correcting formula: as the excess goes higher, the exit_fee increases exponentially, reducing usage and eventually forcing the excess back down. the block-by-block behavior is roughly as follows. if block n processes x exits, then at the end of block n excess_exits increases by x target_exits_per_block, and so the exit_fee in block n+1 increases by a factor of e**((x target_exits_per_block) / exit_fee_update_fraction). hence, it has a similar effect to the existing eip-1559, but is more “stable” in the sense that it responds in the same way to the same total exits regardless of how they are distributed over time. the parameter exit_fee_update_fraction controls the maximum downwards rate of change of the blob gas price. it is chosen to target a maximum downwards change rate of e(target_exits_per_block / exit_fee_update_fraction) ≈ 1.125 per block. the maximum upwards change per block is e((max_exits_per_block target_exits_per_block) / exit_fee_update_fraction) ≈ 2.279. exits inside of the block exits are placed into the actual body of the block (and execution payload in the consensus layer). there is a strong design requirement that the consensus layer and execution layer can execute independently of each other. this means, in this case, that the consensus layer cannot rely upon a synchronous call to the execution layer to get the required exits for the current block. instead, the exits must be embedded in the shared data-structure of the execution payload such that if the execution layer is offline, the consensus layer still has the requisite data to fully execute the consensus portion of the state transition function. backwards compatibility this eip introduces backwards incompatible changes to the block structure and block validation rule set. but neither of these changes break anything related to current user activity and experience. security considerations impact on existing custody relationships there might be existing custody relationships and/or products that rely upon the assumption that the withdrawal credentials cannot trigger exits. we are currently confident that the additional withdrawal credentials feature does not impact the security of existing validators because: the withdrawal credentials ultimately own the funds so allowing them to exit staking is natural with respect to ownership. we are currently not aware of any such custody relationships and/or products that do rely on the lack of this feature. in the event that existing validators/custodians rely on this, then the validators can be exited and restaked utilizing 0x01 withdrawal credentials pointing to a smart contract that simulates this behaviour. copyright copyright and related rights waived via cc0. citation please cite this document as: danny ryan (@djrtwo), mikhail kalinin (@mkalinin), ansgar dietrichs (@adietrichs), hsiao-wei wang (@hwwhww), "eip-7002: execution layer triggerable exits [draft]," ethereum improvement proposals, no. 7002, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7002. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6809: non-fungible key bound token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-6809: non-fungible key bound token an interface for non-fungible key bound tokens, also known as a nfkbt. authors mihai onila (@mihaioro), nick zeman (@nickzcz), narcis cotaie (@narciscro) created 2023-03-31 requires eip-721 table of contents abstract motivation specification ikbt721 (token contract) events interface functions rationale backwards compatibility test cases reference implementation security considerations copyright abstract a standard interface for non-fungible key bound tokens (nfkbt/s), a subset of the more general key bound tokens (kbt/s). the following standardizes an api for tokens within smart contracts and provides basic functionality to the addbindings function. this function designates key wallets1, which are responsible for conducting a safe transfer2. during this process, nfkbt’s are safely approved so they can be spent by the user or an on-chain third-party entity. the premise of nfkbt’s is to provide fully optional security features built directly into the non-fungible asset, via the concept of allow found in the allowtransfer and allowapproval functions. these functions are called by one of the key wallets1 and allow the holding wallet3 to either call the already familiar transferfrom and approve function found in erc-721. responsibility for the nfkbt is therefore split. the holding wallet contains the asset and key wallets have authority over how the assets can be spent or approved. default behaviors4 of a traditional non-fungible erc-721 can be achieved by simply never using the addbindings function. we considered nfkbts being used by every individual who wishes to add additional security to their non-fungible assets, as well as consignment to third-party wallets/brokers/banks/insurers/galleries. nfkbts are resilient to attacks/thefts, by providing additional protection to the asset itself on a self-custodial level. motivation in this fast-paced technologically advancing world, people learn and mature at different speeds. the goal of global adoption must take into consideration the target demographic is of all ages and backgrounds. unfortunately for self-custodial assets, one of the greatest pros is also one of its greatest cons. the individual is solely responsible for their actions and adequately securing their assets. if a mistake is made leading to a loss of funds, no one is able to guarantee their return. from january 2021 through march 2022, the united states federal trade commission received more than 46,0005 crypto scam reports. this directly impacted crypto users and resulted in a net consumer loss exceeding $1 billion6. theft and malicious scams are an issue in any financial sector and oftentimes lead to stricter regulation. however, government-imposed regulation goes against one of this space’s core values. efforts have been made to increase security within the space through centralized and decentralized means. up until now, no one has offered a solution that holds onto the advantages of both whilst eliminating their disadvantages. we asked ourselves the same question as many have in the past, “how does one protect the wallet?”. after a while, realizing the question that should be asked is “how does one protect the asset?”. creating the wallet is free, the asset is what has value and is worth protecting. this question led to the development of kbt’s. a solution that is fully optional and can be tailored so far as the user is concerned. individual assets remain protected even if the seed phrase or private key is publicly released, as long as the security feature was activated. nfkbts saw the need to improve on the widely used non-fungible erc-721 token standard. the security of non-fungible assets is a topic that concerns every entity in the crypto space, as their current and future use cases are continuously explored. nfkbts provide a scalable decentralized security solution that takes security one step beyond wallet security, focusing on the token’s ability to remain secure. the security is on the blockchain itself, which allows every demographic that has access to the internet to secure their assets without the need for current hardware or centralized solutions. made to be a promising alternative, nfkbts inherit all the characteristics of an erc-721. this was done so nfkbts could be used on every dapp that is configured to use traditional non-fungible tokens. during the development process, the potential advantages kbt’s explored were the main motivation factors leading to their creation; completely decentralized: the security features are fully decentralized meaning no third-party will have access to user funds when activated. this was done to truly stay in line with the premise of self-custodial assets, responsibility and values. limitless scalability: centralized solutions require the creation of an account and their availability may be restricted based on location. nfkbt’s do not face regional restrictions or account creation. decentralized security solutions such as hardware options face scalability issues requiring transport logistics, secure shipping and vendor. nfkbt’s can be used anywhere around the world by anyone who so wishes, provided they have access to the internet. fully optional security: security features are optional, customizable and removable. it’s completely up to the user to decide the level of security they would like when using nfkbt’s. default functionality: if the user would like to use nfkbt’s as a traditional erc-721, the security features do not have to be activated. as the token inherits all of the same characteristics, it results in the token acting with traditional non-fungible default behaviors4. however, even when the security features are activated, the user will still have the ability to customize the functionality of the various features based on their desired outcome. the user can pass a set of custom and or default values7 manually or through a dapp. unmatched security: by calling the addbindings function a key wallet1 is now required for the allowtransfer or allowapproval function. the allowtransfer function requires 4 parameters, _tokenid8, _time9, _address10, and _anytoken11, where as the allowapproval function has 2 parameters, _time12 and _numberoftransfers13. in addition to this, nfkbt’s have a safefallback and resetbindings function. the combination of all these prevent and virtually cover every single point of failure that is present with a traditional erc-721, when properly used. security fail-safes: with nfkbts, users can be confident that their tokens are safe and secure, even if the holding wallet3 or one of the key wallets1 has been compromised. if the owner suspects that the holding wallet has been compromised or lost access, they can call the safefallback function from one of the key wallets. this moves the assets to the other key wallet preventing a single point of failure. if the owner suspects that one of the key wallets has been comprised or lost access, the owner can call the resetbindings function from _keywallet114 or _keywallet215. this resets the nfkbt’s security feature and allows the holding wallet to call the addbindings function again. new key wallets can therefore be added and a single point of failure can be prevented. anonymous security: frequently, centralized solutions ask for personal information that is stored and subject to prying eyes. purchasing decentralized hardware solutions are susceptible to the same issues e.g. a shipping address, payment information, or a camera recording during a physical cash pick-up. this may be considered by some as infringing on their privacy and asset anonymity. nfkbt’s ensure user confidentially as everything can be done remotely under a pseudonym on the blockchain. low-cost security: the cost of using nfkbt’s security features correlate to on-chain fees, the current gwei at the given time. as a standalone solution, they are a viable cost-effective security measure feasible to the majority of the population. environmentally friendly: since the security features are coded into the nfkbt, there is no need for centralized servers, shipping, or the production of physical object/s. thus leading to a minimal carbon footprint by the use of nfkbt’s, working hand in hand with ethereum’s change to a pos16 network. user experience: the security feature can be activated by a simple call to the addbindings function. the user will only need two other wallets, which will act as _keywallet114 and _keywallet215, to gain access to all of the benefits nfkbt’s offer. the optional security features improve the overall user experience and ethereum ecosystem by ensuring a safety net for those who decide to use it. those that do not use the security features are not hindered in any way. this safety net can increase global adoption as people can remain confident in the security of their assets, even in the scenario of a compromised wallet. specification ikbt721 (token contract) notes: the following specifications use syntax from solidity 0.8.17 (or above) callers must handle false from returns (bool success). callers must not assume that false is never returned! interface ikbt721 { event accountsecured(address indexed _account, uint256 _nooftokens); event accountresetbinding(address indexed _account); event safefallbackactivated(address indexed _account); event accountenabledtransfer( address _account, uint256 _tokenid, uint256 _time, address _to, bool _anytoken ); event accountenabledapproval( address _account, uint256 _time, uint256 _numberoftransfers ); event ingress(address _account, uint256 _tokenid); event egress(address _account, uint256 _tokenid); struct accountholderbindings { address firstwallet; address secondwallet; } struct firstaccountbindings { address accountholderwallet; address secondwallet; } struct secondaccountbindings { address accountholderwallet; address firstwallet; } struct transferconditions { uint256 tokenid; uint256 time; address to; bool anytoken; } struct approvalconditions { uint256 time; uint256 numberoftransfers; } function addbindings( address _keywallet1, address _keywallet2 ) external returns (bool); function getbindings( address _account ) external view returns (accountholderbindings memory); function resetbindings() external returns (bool); function safefallback() external returns (bool); function allowtransfer( uint256 _tokenid, uint256 _time, address _to, bool _alltokens ) external returns (bool); function gettransferablefunds( address _account ) external view returns (transferconditions memory); function allowapproval( uint256 _time, uint256 _numberoftransfers ) external returns (bool); function getapprovalconditions( address account ) external view returns (approvalconditions memory); function getnumberoftransfersallowed( address _account, address _spender ) external view returns (uint256); function issecurewallet(address _account) external returns (bool); function issecuretoken(uint256 _tokenid) external returns (bool); } events accountsecured event emitted when the _account is securing his account by calling the addbindings function. _amount is the current balance of the _account. event accountsecured(address _account, uint256 _amount) accountresetbinding event emitted when the holder is resetting his keywallets by calling the resetbindings function. event accountresetbinding(address _account) safefallbackactivated event emitted when the holder is choosing to move all the funds to one of the keywallets by calling the safefallback function. event safefallbackactivated(address _account) accountenabledtransfer event emitted when the _account has allowed for transfer _amount of tokens for the _time amount of block seconds for _to address (or if the _account has allowed for transfer all funds though _anytoken set to true) by calling the allowtransfer function. event accountenabledtransfer(address _account, uint256 _amount, uint256 _time, address _to, bool _allfunds) accountenabledapproval event emitted when _account has allowed approval for the _time amount of block seconds by calling the allowapproval function. event accountenabledapproval(address _account, uint256 _time) ingress event emitted when _account becomes a holder. _amount is the current balance of the _account. event ingress(address _account, uint256 _amount) egress event emitted when _account transfers all his tokens and is no longer a holder. _amount is the previous balance of the _account. event egress(address _account, uint256 _amount) interface functions the functions detailed below must be implemented. addbindings function secures the sender account with other two wallets called _keywallet1 and _keywallet2 and must fire the accountsecured event. the function should revert if: the sender account is not a holder or the sender is already secured or the keywallets are the same or one of the keywallets is the same as the sender or one or both keywallets are zero address (0x0) or one or both keywallets are already keywallets to another holder account function addbindings (address _keywallet1, address _keywallet2) external returns (bool) getbindings function the function returns the keywallets for the _account in a struct format. struct accountholderbindings { address firstwallet; address secondwallet; } function getbindings(address _account) external view returns (accountholderbindings memory) resetbindings function note: this function is helpful when one of the two keywallets is compromised. called from a keywallet, the function resets the keywallets for the holder account. must fire the accountresetbinding event. the function should revert if the sender is not a keywallet. function resetbindings() external returns (bool) safefallback function note: this function is helpful when the holder account is compromised. called from a keywallet, this function transfers all the tokens from the holder account to the other keywallet and must fire the safefallbackactivated event. the function should revert if the sender is not a keywallet. function safefallback() external returns (bool); allowtransfer function called from a keywallet, this function is called before a transferfrom or safetransferfrom functions are called. it allows to transfer a tokenid, for a specific time frame, to a specific address. if the tokenid is 0 then there will be no restriction on the tokenid. if the time is 0 then there will be no restriction on the time. if the to address is zero address then there will be no restriction on the to address. or if _anytoken is true, regardless of the other params, it allows any token, whenever, to anyone to be transferred of the holder. the function must fire accountenabledtransfer event. the function should revert if the sender is not a keywallet for a holder or if the owner of the _tokenid is different than the holder. function allowtransfer(uint256 _tokenid, uint256 _time, address _to, bool _anytoken) external returns (bool); gettransferablefunds function the function returns the transfer conditions for the _account in a struct format. struct transferconditions { uint256 tokenid; uint256 time; address to; bool anytoken; } function gettransferablefunds(address _account) external view returns (transferconditions memory); allowapproval function called from a keywallet, this function is called before approve or setapprovalforall functions are called. it allows the holder for a specific amount of _time to do an approve or setapprovalforall and limit the number of transfers the spender is allowed to do through _numberoftransfers (0 unlimited number of transfers in the allowance limit). the function must fire accountenabledapproval event. the function should revert if the sender is not a keywallet. function allowapproval(uint256 _time) external returns (bool) getapprovalconditions function the function returns the approval conditions in a struct format. where time is the block.timestamp until the approve or setapprovalforall functions can be called, and numberoftransfers is the number of transfers the spender will be allowed. struct approvalconditions { uint256 time; uint256 numberoftransfers; } function getapprovalconditions(address _account) external view returns (approvalconditions memory); transferfrom function the function transfers from _from address to _to address the _tokenid token. each time a spender calls the function the contract subtracts and checks if the number of allowed transfers of that spender has reached 0, and when that happens, the approval is revoked using a set approval for all to false. the function must fire the transfer event. the function should revert if: the sender is not the owner or is not approved to transfer the _tokenid or if the _from address is not the owner of the _tokenid or if the sender is a secure account and it has not allowed for transfer this _tokenid through allowtransfer function. function transferfrom(address _from, address _to, uint256 _tokenid) external returns (bool) safetransferfrom function the function transfers from _from address to _to address the _tokenid token. the function must fire the transfer event. the function should revert if: the sender is not the owner or is not approved to transfer the _tokenid or if the _from address is not the owner of the _tokenid or if the sender is a secure account and it has not allowed for transfer this _tokenid through allowtransfer function. function safetransferfrom(address _from, address _to, uint256 _tokenid, bytes memory data) external returns (bool) safetransferfrom function, with data parameter this works identically to the other function with an extra data parameter, except this function just sets data to “”. function safetransferfrom(address _from, address _to, uint256 _tokenid) external returns (bool) approve function the function allows _to account to transfer the _tokenid from the sender account. the function also limits the _to account to the specific number of transfers set in the approvalconditions for that holder account. if the value is 0 then the _spender can transfer multiple times. the function must fire an approval event. if the function is called again it overrides the number of transfers allowed with _numberoftransfers, set in allowapproval function. the function should revert if: the sender is not the current nft owner, or an authorized operator of the current owner the nft owner is secured and has not called allowapproval function or if the _time, set in the allowapproval function, has elapsed. function approve(address _to, uint256 _tokenid) public virtual override(erc721, ierc721) setapprovalforall function the function enables or disables approval for another account _operator to manage all of sender assets. the function also limits the _to account to the specific number of transfers set in the approvalconditions for that holder account. if the value is 0 then the _spender can transfer multiple times. the function emits an approval event indicating the updated allowance. if the function is called again it overrides the number of transfers allowed with _numberoftransfers, set in allowapproval function. the function should revert if: the sender account is secured and has not called allowapproval function or if the _spender is a zero address (0x0) or if the _time, set in the allowapproval function, has elapsed. function setapprovalforall(address _operator, bool _approved) public virtual override(erc721, ierc721) rationale the intent from individual technical decisions made during the development of nfkbts focused on maintaining consistency and backward compatibility with erc-721s, all the while offering self-custodial security features to the user. it was important that nfkbt’s inherited all of erc-721s characteristics to comply with requirements found in dapps which use non-fungible tokens on their platform. in doing so, it allowed for flawless backward compatibility to take place and gave the user the choice to decide if they want their nfkbts to act with default behaviors4. we wanted to ensure that wide-scale implementation and adoption of nfkbts could take place immediately, without the greater collective needing to adapt and make changes to the already flourishing decentralized ecosystem. for developers and users alike, the allowtransfer and allowapproval functions both return bools on success and revert on failures. this decision was done purposefully, to keep consistency with the already familiar erc-721. additional technical decisions related to self-custodial security features are broken down and located within the security considerations section. backwards compatibility kbt’s are designed to be backward-compatible with existing token standards and wallets. existing tokens and wallets will continue to function as normal, and will not be affected by the implementation of nfkbt’s. test cases the assets directory has all the tests. average gas used (gwei): addbindings 155,096 resetbindings 30,588 safefallback 72,221 (depending on how many nfts the holder has) allowtransfer 50,025 allowapproval 44,983 reference implementation the implementation is located in the assets directory. there’s also a diagram with the contract interactions. security considerations nfkbt’s were designed with security in mind every step of the way. below are some design decisions that were rigorously discussed and thought through during the development process. key wallets1: when calling the addbindings function for an nfkbt, the user must input 2 wallets that will then act as _keywallet114 and _keywallet215. they are added simultaneously to reduce user fees, minimize the chance of human error and prevent a pitfall scenario. if the user had the ability to add multiple wallets it would not only result in additional fees and avoidable confusion but would enable a potentially disastrous safefallback situation to occur. for this reason, all kbt’s work under a 3-wallet system when security features are activated. typically if a wallet is compromised, the non-fungible assets within are at risk. with nfkbt’s there are two different functions that can be called from a key wallet1 depending on which wallet has been compromised. scenario: holding wallet3 has been compromised, call safefallback. safefallback: this function was created in the event that the owner believes the holding wallet3 has been compromised. it can also be used if the owner losses access to the holding wallet. in this scenario, the user has the ability to call safefallback from one of the key wallets1. nfkbt’s are then redirected from the holding wallet to the other key wallet. by redirecting the nfkbt’s it prevents a single point of failure. if an attacker were to call safefallback and the nfkbt’s redirected to the key wallet1 that called the function, they would gain access to all the nfkbt’s. scenario: key wallet1 has been compromised, call resetbindings. resetbindings: this function was created in the event that the owner believes _keywallet114 or _keywallet215 has been compromised. it can also be used if the owner losses access to one of the key wallets1. in this instance, the user has the ability to call resetbindings, removing the bound key wallets and resetting the security features. the nfkbt’s will now function as a traditional erc-721 until addbindings is called again and a new set of key wallets are added. the reason why _keywallet114 or _keywallet215 are required to call the resetbindings function is because a holding wallet3 having the ability to call resetbindings could result in an immediate loss of nfkbt’s. the attacker would only need to gain access to the holding wallet and call resetbindings. in the scenario that 2 of the 3 wallets have been compromised, there is nothing the owner of the nfkbt’s can do if the attack is malicious. however, by allowing 1 wallet to be compromised, holders of non-fungible tokens built using the nfkbt standard are given a second chance, unlike other current standards. the allowtransfer function is in place to guarantee a safe transfer2, but can also have default values7 set by a dapp to emulate default behaviors3 of a traditional erc-721. it enables the user to highly specify the type of transfer they are about to conduct, whilst simultaneously allowing the user to unlock all the nfkbt’s to anyone for an unlimited amount of time. the desired security is completely up to the user. this function requires 4 parameters to be filled and different combinations of these result in different levels of security; parameter 1 _tokenid8: this is the id of the nfkbt that will be spent on a transfer. parameter 2 _time9: the number of blocks the nfkbt can be transferred starting from the current block timestamp. parameter 3 _address10: the destination the nfkbt will be sent to. parameter 4 _anytoken11: this is a boolean value. when false, the transferfrom function takes into consideration parameters 1, 2 and 3. if the value is true, the transferfrom function will revert to a default behavior4, the same as a traditional erc-721. the allowtransfer function requires _keywallet114 or _keywallet215 and enables the holding wallet3 to conduct a transferfrom within the previously specified parameters. these parameters were added in order to provide additional security by limiting the holding wallet in case it was compromised without the user’s knowledge. the allowapproval function provides extra security when allowing on-chain third parties to use your nfkbt’s on your behalf. this is especially useful when a user is met with common malicious attacks e.g. draining dapp. this function requires 2 parameters to be filled and different combinations of these result in different levels of security; parameter 1 _time12: the number of blocks that the approval of a third-party service can take place, starting from the current block timestamp. parameter 2 _numberoftransfers_13: the number of transactions a third-party service can conduct on the user’s behalf. the allowapproval function requires _keywallet114 or _keywallet215 and enables the holding wallet3 to allow a third-party service by using the approve function. these parameters were added to provide extra security when granting permission to a third-party that uses assets on the user’s behalf. parameter 1, _time12, is a limitation to when the holding wallet can approve a third-party service. parameter 2, _numberoftransfers13, is a limitation to the number of transactions the approved third-party service can conduct on the user’s behalf before revoking approval. copyright copyright and related rights waived via cc0. the key wallet/s refers to _keywallet1 or _keywallet2 which can call the safefallback, resetbindings, allowtransfer and allowapproval functions. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 a safe transfer is when 1 of the key wallets safely approved the use of the nfkbt’s. ↩ ↩2 the holding wallet refers to the wallet containing the nfkbt’s. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 a default behavior/s refers to behavior/s present in the preexisting non-fungible erc-721 standard. ↩ ↩2 ↩3 ↩4 the number of crypto scam reports the united states federal trade commission received, from january 2021 through march 2022. ↩ the amount stolen via crypto scams according to the united states federal trade commission, from january 2021 through march 2022. ↩ a default value/s refer to a value/s that emulates the non-fungible erc-721 default behavior/s. ↩ ↩2 the _tokenid represents the id of the nfkbt intended to be spent. ↩ ↩2 the _time in allowtransfer represents the number of blocks a transferfrom can take place in. ↩ ↩2 the _address represents the address that the nfkbt will be sent to. ↩ ↩2 the _anytoken is a bool that can be set to true or false. ↩ ↩2 the _time in allowapproval represents the number of blocks an approve can take place in. ↩ ↩2 ↩3 the _numberoftransfers is the number of transfers a third-party entity can conduct via transferfrom on the user’s behalf. ↩ ↩2 ↩3 the _keywallet1 is 1 of the 2 key wallets set when calling the addbindings function. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 the _keywallet2 is 1 of the 2 key wallets set when calling the addbindings function. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 a pos protocol, proof-of-stake protocol, is a cryptocurrency consensus mechanism for processing transactions and creating new blocks in a blockchain. ↩ citation please cite this document as: mihai onila (@mihaioro), nick zeman (@nickzcz), narcis cotaie (@narciscro), "erc-6809: non-fungible key bound token," ethereum improvement proposals, no. 6809, march 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6809. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5003: insert code into eoas with authusurp ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-5003: insert code into eoas with authusurp allow migrating away from ecdsa by deploying code in place of an externally owned account. authors dan finlay (@danfinlay), sam wilson (@samwilsn) created 2022-03-26 discussion link https://ethereum-magicians.org/t/eip-5003-auth-usurp-publishing-code-at-an-eoa-address/8979 requires eip-3074, eip-3607 table of contents abstract motivation specification conventions authusurp (0xf8) rationale backwards compatibility security considerations copyright abstract this eip introduces a new opcode, authusurp, which deploys code at an eip-3074 authorized address. for externally owned accounts (eoas), together with eip-3607, this effectively revokes the original signing key’s authority. motivation eoas currently hold a significant amount of user-controlled value on ethereum blockchains, but are limited by the protocol in a variety of critical ways. these accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. there are countless other benefits that come from having a contract account or account abstraction, like choosing one’s own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine. new users have access to these benefits using smart contract wallets, and new contracts can adopt recent standards to enable app-layer account abstraction (like eip-4337), but these would neglect the vast majority of existing ethereum users’ accounts. these users exist today, and they also need a path to achieving their security goals. those added benefits would mostly come along with eip-3074 itself, but with one significant shortcoming: the original signing key has ultimate authority for the account. while an eoa could delegate its authority to some additional contract, the key itself would linger, continuing to provide an attack vector, and a constantly horrifying question lingering: have i been leaked? in other words, eip-3074 can only grant authority to additional actors, but never revoke it. today’s eoas have no option to rotate their keys. a leaked private key (either through phishing, or accidental access) cannot be revoked. a prudent user concerned about their key security might migrate to a new secret recovery phrase but at best this requires a transaction per asset (making it extremely expensive), and at worst, some powers (like hard-coded owners in a smart contract) might not be transferable at all. we know that eoas cannot provide ideal user experience or safety, and there is a desire in the community to change the norm to contract-based accounts, but if that transition is designed without regard for the vast majority of users today—for whom ethereum has always meant eoas—we will be continually struggling against the need to support both of these userbases. this eip provides a path not to enshrine eoas, but to provide a migration path off of them, once and for all. this proposal combines well with, but is distinct from, eip-3074, which provides opcodes that could enable any externally owned account (eoa) to delegate its signing authority to an arbitrary smart contract. it allows an eoa to authorize a contract account to act on its behalf without forgoing its own powers, while this eip provides a final migration path off the eoa’s original signing key. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. conventions top n the nth most recently pushed value on the evm stack, where top 0 is the most recent. invalid execution execution that is invalid and must exit the current execution frame immediately, consuming all remaining gas (in the same way as a stack underflow or invalid jump). empty account account where its balance is 0, its nonce is 0, and it has no code. authusurp (0xf8) a new opcode authusurp shall be created at 0xf8. it shall take two stack elements and return one stack element. input stack value top 0 offset top 1 length output stack value top 0 address behavior authusurp behaves identically to create (0xf0), except as described below: if authorized (as defined in eip-3074) is unset, execution is invalid. if authorized points to an empty account, then static_gas remains 32,000. otherwise, static_gas shall be 7,000. authusurp does not check the nonce of the authorized account. the initcode runs at the address authorized. if the initcode returns no bytes, its execution frame must be reverted, and authusurp returns zero. after executing the initcode, but before the returned code is deployed, if the account’s code is non-empty, the initcode’s execution frame must be reverted, and authusurp returns zero. the code is deployed into the account with the address authorized. rationale authusurp does not check the nonce of the authorized account because it must work with accounts that have previously sent transactions. when using authusurp, if the initcode were to deploy a zero-length contract, there would be no way to prevent using authusurp again later. the account’s code must be checked immediately before deploying to catch the situation where the initcode attempts to authusurp at the same address. this is unnecessary with other deployment instructions because they increment and check the account’s nonce. backwards compatibility authusurp with eip-3607 revokes the authority of the original ecdsa signature to send transactions from the account. this is completely new behavior, although it is somewhat similar to the create2 opcode. security considerations contracts using ecdsa signatures outside of transactions will not be aware that the usurped account is no longer controlled by a private key. this means that, for example, the private key will always have access to the permit function on token contracts. this can—and should—be mitigated by modifying the ecrecover pre-compiled contract. copyright copyright and related rights waived via cc0. citation please cite this document as: dan finlay (@danfinlay), sam wilson (@samwilsn), "eip-5003: insert code into eoas with authusurp [draft]," ethereum improvement proposals, no. 5003, march 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5003. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. launching the ether sale | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search launching the ether sale posted by vitalik buterin on july 22, 2014 organizational first of all, i would like to thank the community, and especially those close to the project who have in many cases abandoned their jobs to dedicate their time to it, for their extreme patience regarding the launch of the ether sale. we have been promising that the sale would arise in two weeks for six months, and many team members have endured substantial hardships because of expectations that we set regarding when we would be able to provide funding. we certainly miscalculated the sheer difficulty of navigating the relevant legal processes in the united states and switzerland, as well as the surprisingly intricate technical issues surrounding setting up a secure sale website and cold wallet system. however, the long wait is finally over, and we are excited to announce the launch of the sale. in the intervening six months, our time has been spent on the following: developing the ethereum clients, to the point where we now have four full implementations of the protocol, of which two are fully compatible and the other two nearly so. originally, the intent was for only three implementations; however, a member of the community (roman mandeleil) has independently come forward with a functional java client. poc5 has been released today. developing the ethereum programming languages and compilers, to the point where we have moderately stable versions of serpent, lll and mutan. developing the ethereum protocol. major changes between february and june include: the transactions-pay-for-computation system, where a transaction specifies the amount of "gas" that it is allowed to consume and pre-pays a fee for it. originally, contracts paid for computation, requiring every contract to have a security "wrapper" mandating a minimum fee to avoid balance-starvation attacks. the concept of a recursive virtual machine, where contracts can "call" other contracts like functions and receive "return values" in response. this allows for a high level of generalization and code reuse in the blockchain, cutting down bloat. a 10 to 20-second block time, down from 60s. this will be added in poc6. the concept of "micro-chains", where the top-level block header will only contain pow-relevant information, reducing the minimum storage and bandwidth requirements for a light node by 4x (although the fast block time will once again increase these requirements by 4x). this will be added in poc6. the placement of transactions into a merkle tree, allowing for the development of a light client protocol for verification of individual transaction execution. the concept of memory as a byte array, making it easier to port existing compilers to compiling ethereum scripts. mid-stage developments in the mining algorithm thanks primarily to the work of vlad zamfir. more details should be released soon. developing an increasingly large repertoire of testing facilities in order to help ensure cross-client compatibility. setting up our legal organizational structure in switzerland. legal due-diligence processes in the united states. ether will be purchasable directly through our website at https://ethereum.org. there are a number of documents providing more details on the sale as well, including a development plan (đξv plan), roadmap, intended use of revenue document, terms and conditions of the ethereum genesis sale, ether product purchase agreement, and updated white paper and yellow paper. particularly note the following: ether will not be usable or transferable until the launch of the genesis block. that is to say, when you buy ether and download your wallet, you will not be able to do anything with it until the genesis block launches. the price of ether is initially set to a discounted price of 2000 eth per btc, and will stay this way for 14 days before linearly declining to a final rate of 1337 eth per btc. the sale will last 42 days, concluding at 23:59 zug time september 2. the expected launch time for the genesis block is winter 2014-2015. this date has been continually pushed back in large part due to funding delays, but development should soon start to proceed much more quickly. ether is a product, not a security or investment offering. ether is simply a token useful for paying transaction fees or building or purchasing decentralized application services on the ethereum platform; it does not give you voting rights over anything, and we make no guarantees of its future value. we are not blocking the us after all. yay. it is very likely that alternative versions of ethereum (“alt-etherea” or “forks”) will be released as separate blockchains, and these chains will compete against the official ethereum for value. successfully purchasing eth from the genesis sale only guarantees that you will receive eth on the official network, not any forks. the terms and conditions of the ethereum genesis sale, and the ether product purchase agreement, are the only authoritative documents regarding the sale. any statements that we have made up to this point are null and void. the ethereum.org website, the blog posts since taylor gerring's recent howto and other posts we have made on various forums including our forum and reddit are to be treated as informal communications designed to keep the community updated on what is happening with ethereum. the annual issuance rate is 0.26x the initial quantity of ether sold, reduced from the 0.50x that had been proposed in january. we may choose later on to adopt alternative consensus strategies, such as hybrid proof of stake, so future patches may reduce the issuance rate lower. however, we make absolutely no promises of this, except that the issuance rate will not exceed 26.00% per annum of the quantity of ether sold in the genesis sale. there are two endowment pools, each 0.099x the initial quantity of ether sold, that will be allocated in the first case to early contributors to the project and in the second case to a long-term endowment to our non-profit foundation (see sale docs for more info). this is reduced from our proposal in april of 0.075x to early contributors and 0.225x to a foundation. we reserve the right to use up to 5000 btc from the pre-sale while the pre-sale is running in order to speed up development. we may or may not take this option depending on community response; if done at all it will be done transparently. if you are eligible for backpay or a share of the early contributor pool, you will be contacted soon. do not refresh the page while using the ether sale website. if you purchase ether, do not lose your wallet file or your password or you will never be able to access your ether. additionally, make sure you download your wallet in the first place. the exodus address is 36prz1khympqsyaqxsg8vwbuiq2eogxlo2; however, do not send btc to this address directly, since transactions that are not properly formatted will be invalid and treated as gifts to ethereum switzerland gmbh. use the sale application on the website. unlike some other projects, however, paying with btc using our sale application from a coinbase account or an exchange account poses no problems. the btc address that you send from does not matter. for advanced users and those who are uncomfortable with purchasing through a website, a python library for making purchases is also available at https://github.com/ethereum/pyethsaletool. the address is a 3-of-4 cold storage, multisig setup, between four centers which are themselves protected via mechanisms such as m-of-n shamir's secret sharing. check this transaction on blockchain.info, input 4, to see proof that we are capable of spending funds from the address. we will be releasing a more detailed description of the cold storage policy soon, although strategically important variables (eg. precise locations of the sites, passwords, combinations to safes) will unfortunately be kept secret. more information will be released throughout the sale, and we will soon have an ama on reddit. we look forward to continuing this exciting journey together! previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-1898: add `blockhash` to defaultblock methods ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-1898: add `blockhash` to defaultblock methods add `blockhash` option to json-rpc methods that currently support defaultblock parameter. authors charles cooper (@charles-cooper) created 2019-04-01 discussion link https://ethereum-magicians.org/t/eip-1898-add-blockhash-option-to-json-rpc-methods-that-currently-support-defaultblock-parameter/11757 requires eip-234 table of contents abstract specification rationale backwards compatibility test cases security considerations copyright abstract for json-rpc methods which currently accept a default block parameter, additionally allow the parameter to be a block hash. this eip can be considered a generalization of eip-234. it would enable clients to unambiguously specify the block they want to query for certain json-rpc methods, even if the block is not in the canonical chain. this allows clients to maintain a coherent picture of blockchain state that they are interested in, even in the presence of reorgs, without requiring that the node maintain a persistent connection with the client or store any client-specific state. specification the following json-rpc methods are affected: eth_getbalance eth_getstorageat eth_gettransactioncount eth_getcode eth_call eth_getproof the following options, quoted from the ethereum json-rpc spec, are currently possible for the defaultblock parameter: hex string an integer block number string “earliest” for the earliest/genesis block string “latest” for the latest canonical block string “pending” for the pending state/transactions string “safe” for the most recent safe block string “finalized” for the most recent finalized block since there is no way to clearly distinguish between a data parameter and a quantity parameter, this eip proposes a new scheme for the block parameter. the following option is additionally allowed: object blocknumber: quantity a block number blockhash: data a block hash if the block is not found, the callee should raise a json-rpc error (the recommended error code is -32001: resource not found). if the tag is blockhash, an additional boolean field may be supplied to the block parameter, requirecanonical, which defaults to false and defines whether the block must be a canonical block according to the callee. if requirecanonical is false, the callee should raise a json-rpc error only if the block is not found (as described above). if requirecanonical is true, the callee should additionally raise a json-rpc error if the block is not in the canonical chain (the recommended error code is -32000: invalid input and in any case should be different than the error code for the block not found case so that the caller can distinguish the cases). the block-not-found check should take precedence over the block-is-canonical check, so that if the block is not found the callee raises block-not-found rather than block-not-canonical. to maintain backwards compatibility, the block number may be specified either as a hex string or using the new block parameter scheme. in other words, the following are equivalent for the default block parameter: "earliest" "0x0" { "blocknumber": "0x0" } { "blockhash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3" } (hash of the genesis block on the ethereum main chain) { "blockhash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requirecanonical": true } { "blockhash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requirecanonical": false } rationale currently, the state-querying json-rpc methods specified above have no option to unambiguously specify which block to query the state for. this can cause issues for applications which need to make multiple calls to the rpc. for instance, a wallet which just executed a transfer may want to display the balances of both the sender and recipient. if there is a re-org in between when the balance of the sender is queried via eth_getbalance and when the balance of the recipient is queried, the balances may not reconcile. as a slightly more complicated example, the ui for a decentralized exchange (which hosts orders on-chain) may walk a list of orders by calling eth_call for each of them to get the order data. another type of use case is where an application needs to make a decision based on multiple pieces of state, e.g. a payout predicated on simultaneous ownership of two nfts. in order to ensure that the state is coherent (i.e., eth_call was called with exactly the same block for every call), the application may currently use one of several strategies: decide on a block number to use (e.g., the latest block number known to the application). after each eth_call using that block number, call eth_getblockbynumber, also with that block number. if the block hash does not match the known hash for that block number, rollback the current activity and retry from the beginning. this adds o(n) invocations as baseline overhead and another o(n) invocations for every retry needed. moreover, there is no way to detect the (unlikely but possible) case that the relevant block was reorged out before eth_call, and then reorged back in before eth_getblockbynumber. rely on logs, which can be queried unambiguously thanks to the blockhash parameter. however, this requires semantic support from the smart contract; if the smart contract does not emit appropriate events, the client will not be able to reconstruct the specific state it is interested in. rely on non-standard extensions like parity_subscribe. this requires a persistent connection between the client and node (via ipc or websockets), increases coupling between the client and the node, and cannot handle use cases where there are dependencies between invocations of eth_call, for example, walking a linked list. allowing eth_call and friends to unambiguously specify the block to be queried give the application developer a robust and intuitive way to solve these problems. multiple sequential queries will query the same state, enabling the application developer to not worry about inconsistencies in their view of the blockchain state. backwards compatibility backwards compatible. test cases eth_getstorageat [ "0x

", { "blocknumber": "0x0" } -> return storage at given address in genesis block eth_getstorageat [ "0x

", { "blockhash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3" } -> return storage at given address in genesis block eth_getstorageat [ "0x

", { "blockhash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requirecanonical": false } -> return storage at given address in genesis block eth_getstorageat [ "0x

", { "blockhash": "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3", "requirecanonical": true } -> return storage at given address in genesis block eth_getstorageat [ "0x

", { "blockhash": "0x" } -> raise block-not-found error eth_getstorageat [ "0x

", { "blockhash": "0x", "requirecanonical": false } -> raise block-not-found error eth_getstorageat [ "0x

", { "blockhash": "0x", "requirecanonical": true } -> raise block-not-found error eth_getstorageat [ "0x

", { "blockhash": "0x" } -> return storage at given address in specified block eth_getstorageat [ "0x

", { "blockhash": "0x", "requirecanonical": false } -> return storage at given address in specified block eth_getstorageat [ "0x

", { "blockhash": "0x", "requirecanonical": true } -> raise block-not-canonical error security considerations none copyright copyright and related rights waived via cc0. citation please cite this document as: charles cooper (@charles-cooper), "eip-1898: add `blockhash` to defaultblock methods [draft]," ethereum improvement proposals, no. 1898, april 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1898. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1682: storage rent ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-1682: storage rent authors felix j lange (@fjl), martin holst swende (@holiman) created 2018-11-10 discussion link https://ethereum-magicians.org/t/storage-rent-eip/2357 table of contents abstract motivation specification changes to state charging rent new evm opcodes rationale why do we need a separate rent balance? why restoration? implementation impact backwards compatibility test cases implementation copyright abstract this eip describes a scheme to charge for data in state, and ‘archive’ data which is no longer being paid for. it also describes how resurrection of ‘archived’ data happens. motivation the ethereum blockchain in its current form is not sustainable because it grows indefinitely. this is true of any blockchain, but ethereum grows faster than most chains. many implementation strategies to slow down growth exist. a common strategy is ‘state pruning’ which discards historical state, keeping only the active copy of contract data and a few recent versions to deal with short-range chain reorganizations. several implementations also employ compression techniques to keep the active copy of the state as small as possible. a full node participating in consensus today requires storing large amounts of data even with advanced storage optimizations applied. future storage requirements are unbounded because any data stored in a contract must be retained forever as dictated by the protocol. this eip attempts to correct this by adding new consensus rules that put an upper bound on the size of the ethereum state. adding these new rules changes fundamental guarantees of the system and requires a hard fork. users of ethereum already pay for the creation and modification of accounts and their storage entries. under the rules introduced in this eip, users must also pay to keep accounts accessible. a similar rent scheme was proposed in eip-103 but rejected even back then because the proposal would’ve upset peoples expectations. as implementers of ethereum, we still feel that state rent is the right path to long-term sustainability of the ethereum blockchain and that its undesirable implications can be overcome with off-protocol tooling and careful design. specification the cost of storing an account over time is called rent. the amount of rent due depends on the size of the account. the ether that is paid for rent is destroyed. the rent is deducted whenever an account is touched. rent can be paid from the account’s regular balance or from its ‘rent balance’. accounts can be endowed with rent balance through a new evm opcode. when rent is charged, it is first taken from the rent balance. when rent balance is zero, it is instead charged from the account’s regular balance instead. the reason to separate balance and rent balance is that certain contracts do not accept ether sends, or always send the entire balance off to some other destination. for these cases, a separaterent balance is required. when an account’s balance is insufficient to pay rent, the account becomes inactive. its storage and contract code are removed. inactive accounts cannot be interacted with, i.e. it behaves as if it has no contract code. inactive accounts can be restored by re-uploading their storage. to restore an inactive account a, a new account b is created with arbitrary code and its storage modified with sstore operations until it matches the storage root of a. account b can restore a through the restoreto opcode. this means the cost of restoring an account is equivalent to recreating it via successive sstore operations. changes to state at the top level, a new key size is added to the accounts trie. this key tracks the total number of trie nodes across all accounts, including storage trie nodes. to track rent, the structure of account entries is changed as well. before processing the block in which this eip becomes active, clients iterate the whole state once to count the number of trie nodes and to change the representation of all accounts to the new format. account representation account = [nonce, balance, storageroot, codehash, rentbalance, rentblock, storagesize] each account gets three additional properties: rentbalance, rentblock and storagesize. the rentbalace field tracks the amount of rent balance available to the account. upon self-destruction any remaining rent balance is transferred to the beneficiary. any modification of the account recomputes its current rent balance. the rentblock field tracks the block number in which the rent balance was last recomputed. upon creation, this field is initialized with the current block number. rentblock is also updated with the current block number whenever the account is modified. the storagesize field tracks the amount of storage related to the account. it is a number containing the number of storage slots currently set. the storagesize of an inactive account is zero. charging rent there is a new protocol constant max_storage_size that specifies the upper bound on the number of state tree nodes: max_storage_size = 2**32 # ~160gb of state a ‘storage fee factor’ for each block is derived from this constant such that fees increase as the limit is approached. def storagefee_factor(block): ramp = max_storage_size / (max_storage_size total_storage_size(block)) return 2**22 * ramp when a block is processed, rent is deducted from all accounts modified by transactions in the block after the transactions have been processed. the amount due for each account is based on the account’s storage size. def rent(prestate, poststate, addr, currentblock): fee = 0 for b in range(prestate[addr].rentblock+1, currentblock-1): fee += storagefee_factor(b) * prestate[addr].storagesize return fee + storagefee_factor(currentblock) * poststate[addr].storagesize def charge_rent(prestate, poststate, addr, currentblock): fee = rent(prestate, poststate, addr, currentblock) if fee <= poststate[addr].rentbalance: poststate[addr].rentbalance -= fee else: fee -= poststate[addr].rentbalance poststate[addr].rentbalance = 0 poststate[addr].balance -= min(poststate[addr].balance, fee) poststate[addr].rentblock = currentblock new evm opcodes payrent at any time, the rent balance of an account may be topped up by the payrent opcode. payrent deducts the given amount of ether from the account executing the opcode and adds it to the rent balance of the address specified as beneficiary. any participant can pay the rent for any other participant. gas cost: tbd rentbalance the rent balance of an account may be queried through the rentbalance opcode. it pushes the rentbalance field of the given address to the stack. gas cost: like extcodehash. ssize this opcode pushes the storagesize field of the given account to the stack. gas cost: like extcodehash. restoreto this opcode restores the inactive account at the given address. this is a bit like selfdestruct but has more specific semantics. the account at addr must be inactive (i.e. have storagesize zero) and its storageroot must match the storageroot of the contract executing restoreto. the codeaddr specifies the address of a contract from which code is taken. the code of the codeaddr account must match the codehash of addr. if all these preconditions are met, restoreto transfers the storage of the account executing the opcode to addr and resets its storagesize to the full size of the storage. the code of addr is restored as well. restoreto also transfers any remaining balance and rent balance to addr. the contract executing restoreto is deleted. gas cost: tbd rationale why do we need a separate rent balance? accounts need a separate rent balance because some contracts are non-payable, i.e. they reject regular value transfers. such contracts might not be able to keep themselves alive, but users of those contracts can keep them alive by paying rent for them. having the additional balance also makes things easier for contracts that hold balance on behalf of a user. consider the canonical crowdfunding example, a contract which changes behavior once a certain balance is reached and which tracks individual user’s balances. deducting rent from the main balance of the contract would mess up the contract’s accounting, leaving it unable to pay back users accurately if the threshold balance isn’t reached. why restoration? one of the fundamental guarantees provided by ethereum is that changes to contract storage can only be made by the contract itself and storage will persist forever. if you hold a token balance in a contract, you’ll have those tokens forever. by adding restoration, we can maintain this guarantee to a certain extent. implementation impact the proposed changes tries to fit within the existing state transition model. note that there is no mechanism for deactivating accounts the moment they can’t pay rent. users must touch accounts to ensure their storage is removed because we’d need to track all accounts and their rent requirements in an auxlilary data structure otherwise. backwards compatibility tba test cases tba implementation tba copyright copyright and related rights waived via cc0. citation please cite this document as: felix j lange (@fjl), martin holst swende (@holiman), "eip-1682: storage rent [draft]," ethereum improvement proposals, no. 1682, november 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1682. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6327: elastic signature ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-6327: elastic signature use password to sign data as private key authors george (@jxrow) created 2023-01-13 discussion link https://ethereum-magicians.org/t/eip-6327-elastic-signature-es/12554 table of contents abstract motivation use case specification ielasticsignature interface rationale backwards compatibility reference implementation security considerations copyright abstract elastic signature (es) aims to sign data with a human friendly secret. the secret will be verified fully on-chain and is not stored anywhere. a user can change the secret as often as they need to. the secret does not have a fixed length. the secret will be like a password, which is a better understood concept than private key. this is specifically true for non-technical users. this eip defines a smart contract interface to verify and authorize operations with es. motivation what would a changeable “private key” enable us? for years, we have been looking for ways to lower on-boarding barrier for users, especially those with less technical experiences. private key custody solutions seem to provide an user friendly on-boarding experience, but it is vendor dependent and is not decentralized. es makes a breakthrough with zero-knowledge technology. users generate proof of knowing the secret and a smart contract will verify the proof. use case es is an alternative signing algorithm. it is not an either-or solution to the private key. it is designed to serve as an additional signing mechanism on top of the private key signature. a defi app can utilize es into their transfer fund process. users will be required to provide their passwords to complete the transaction. this gives an extra protection even if the private key is compromised. es can also be used as a plugin to a smart contract wallet, like account abstraction erc-4337. a decentralized password is picked instead of the private key. this could lead to a smooth onboarding experiences for new ethereum dapp users. specification let: pwdhash represents the hash of the private secret (password). datahash represents the hash of an intended transaction data. fullhash represents the hash of datahash and all the well-known variables. expiration is the timestamp after which the intended transaction expires. allhash represents the hash of fullhash and pwdhash. there are three parties involved, verifier, requester and prover. a verifier, should compute fullhash from a datahash, which is provided by the requester. should derive pwdhash for a given address. the address can be an eoa or a smart contract wallet. should verify the proof with the derived pwdhash, the computed fullhash and a allhash, which is submitted by the requester. a requester should generate datahash and decide an expiration. shall request a verification from the verifier with, proof and allhash which are provided by the prover; datahash; expiration. a prover should generate the proof and allhash from, datahash and expiration which are agreed with the requester; nonce and other well-known variables. there are also some requirements. well-known variable should be available to all parties. should include a nonce. should include a chainid. may include any variable that is specific to the verifier. public statements should include, one reflecting the pwdhash; one reflecting the fullhash; one reflecting the allhash. the computation of fullhash should be agreed by both the verifier and the prover. the computation of datahash ielasticsignature interface this is the verifier interface. pragma solidity ^0.8.0; interface ielasticsignature { /** * event emitted after user set/reset their password * @param user an user's address, for whom the password hash is set. it could be a smart contract wallet address * or an eoa wallet address. * @param pwdhash a password hash */ event setpassword(address indexed user, uint indexed pwdhash); /** * event emitted after a successful verification performed for an user * @param user an user's address, for whom the submitted `proof` is verified. it could be a smart contract wallet * address or an eoa wallet address. * @param nonce a new nonce, which is newly generated to replace the last used nonce. */ event verified(address indexed user, uint indexed nonce); /** * get `pwdhash` for a user * @param user a user's address * @return the `pwdhash` for the given address */ function pwdhashof(address user) external view returns (uint); /** * update an user's `pwdhash` * @param proof1 proof generated by the old password * @param expiration1 old password signing expiry seconds * @param allhash1 allhash generated with the old password * @param proof2 proof generated by the new password * @param pwdhash2 hash of the new password * @param expiration2 new password signing expiry seconds * @param allhash2 allhash generated with the new password */ function resetpassword( uint[8] memory proof1, uint expiration1, uint allhash1, uint[8] memory proof2, uint pwdhash2, uint expiration2, uint allhash2 ) external; /** * verify a proof for a given user * it should be invoked by other contracts. the other contracts provide the `datahash`. the `proof` is generated by * the user. * @param user a user's address, for whom the verification will be carried out. * @param proof a proof generated by the password * @param datahash the data what user signing, this is the hash of the data * @param expiration number of seconds from now, after which the proof is expired * @param allhash public statement, generated along with the `proof` */ function verify( address user, uint[8] memory proof, uint datahash, uint expiration, uint allhash ) external; } verify function should be called by another contract. the other contract should generate the datahash to call this. the function should verify if the allhash is computed correctly and honestly with the password. rationale the contract will store everyone’s pwdhash. the chart below shows zk circuit logic. to verify the signature, it needs proof, allhash, pwdhash and fullhash. the prover generates proof along with the public outputs. they will send all of them to a third-party requester contract. the requester will generate the datahash. it sends datahash, proof, allhash, expiration and prover’s address to the verifier contract. the contract verifies that the datahash is from the prover, which means the withdrawal operation is signed by the prover’s password. backwards compatibility this eip is backward compatible with previous work on signature validation since this method is specific to password based signatures and not eoa signatures. reference implementation example implementation of a signing contract: pragma solidity ^0.8.0; import "../interfaces/ielasticsignature.sol"; import "./verifier.sol"; contract zkpass is ielasticsignature { verifier verifier = new verifier(); mapping(address => uint) public pwdhashof; mapping(address => uint) public nonceof; constructor() { } function resetpassword( uint[8] memory proof1, uint expiration1, uint allhash1, uint[8] memory proof2, uint pwdhash2, uint expiration2, uint allhash2 ) public override { uint nonce = nonceof[msg.sender]; if (nonce == 0) { //init password pwdhashof[msg.sender] = pwdhash2; nonceof[msg.sender] = 1; verify(msg.sender, proof2, 0, expiration2, allhash2); } else { //reset password // check old pwdhash verify(msg.sender, proof1, 0, expiration1, allhash1); // check new pwdhash pwdhashof[msg.sender] = pwdhash2; verify(msg.sender, proof2, 0, expiration2, allhash2); } emit setpassword(msg.sender, pwdhash2); } function verify( address user, uint[8] memory proof, uint datahash, uint expiration, uint allhash ) public override { require( block.timestamp < expiration, "zkpass::verify: expired" ); uint pwdhash = pwdhashof[user]; require( pwdhash != 0, "zkpass::verify: user not exist" ); uint nonce = nonceof[user]; uint fullhash = uint(keccak256(abi.encodepacked(expiration, block.chainid, nonce, datahash))) / 8; // 256b->254b require( verifyproof(proof, pwdhash, fullhash, allhash), "zkpass::verify: verify proof fail" ); nonceof[user] = nonce + 1; emit verified(user, nonce); } /////////// util //////////// function verifyproof( uint[8] memory proof, uint pwdhash, uint fullhash, //254b uint allhash ) internal view returns (bool) { return verifier.verifyproof( [proof[0], proof[1]], [[proof[2], proof[3]], [proof[4], proof[5]]], [proof[6], proof[7]], [pwdhash, fullhash, allhash] ); } } verifier.sol is auto generated by snarkjs, the source code circuit.circom is below pragma circom 2.0.0; include "../../node_modules/circomlib/circuits/poseidon.circom"; template main() { signal input in[3]; signal output out[3]; component poseidon1 = poseidon(2); component poseidon2 = poseidon(2); poseidon1.inputs[0] <== in[0]; //pwd poseidon1.inputs[1] <== in[1]; //address out[0] <== poseidon1.out; //pwdhash poseidon2.inputs[0] <== poseidon1.out; poseidon2.inputs[1] <== in[2]; //fullhash out[1] <== in[2]; //fullhash out[2] <== poseidon2.out; //allhash } component main = main(); security considerations since the pwdhash is public, it is possible to be crack the password. we estimate the poseidon hash rate of rtx3090 would be 100mhash/s, this is the estimate of crack time: 8 chars (number) : 1 secs 8 chars (number + english) : 25 days 8 chars (number + english + symbol) : 594 days 12 chars (number) : 10000 secs 12 chars (number + english) : 1023042 years 12 chars (number + english + symbol) : 116586246 years the crack difficulty of private key is 2^256, the crack difficulty of 40 chars (number + english + symbol) is 92^40, 92^40 > 2^256, so when password is 40 chars , it is more difficult to be crack than private key. copyright copyright and related rights waived via cc0. citation please cite this document as: george (@jxrow), "erc-6327: elastic signature [draft]," ethereum improvement proposals, no. 6327, january 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6327. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1959: new opcode to check if a chainid is part of the history of chainids ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1959: new opcode to check if a chainid is part of the history of chainids authors ronan sandford (@wighawag) created 2019-04-20 discussion link https://ethereum-magicians.org/t/eip-1959-valid-chainid-opcode/3170 requires eip-155 table of contents simple summary abstract motivation specification rationale test cases implementation backwards compatibility references copyright simple summary to protect off-chain messages from being reused across different chain, a mechanism need to be given to smart contract to only accept messages for that chain. since a chain can change its chainid, the mechanism should consider old chainid valid. abstract this eip adds an opcode that returns whether the specific number passed in has been a valid chainid (eip-155 unique identifier) in the history of the chain (including the current chainid). motivation eip-155 proposes to use the chain id to prevent replay attacks between different chains. it would be a great benefit to have the same possibility inside smart contracts when handling signatures, especially for layer 2 signature schemes using eip-712. eip-1344 is attempting to solve this by giving smart contract access to the tip of the chainid history. this is insufficient as such value is changing. hence why eip-1344 describes a contract based solution to work around the problem. it would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in eip-1344. specification adds a new opcode valid_chainid at 0x46, which uses 1 stack argument : a 32 bytes value that represent the chainid to test. it will push 0x1 onto the stack if the uint256 value is part of the history (since genesis) of chainids of that chain, 0x0 otherwise. the operation costs g_blockhash to execute. the cost of the operation might need to be adjusted later as the number of chainid in the history of the chain grows. note though that the alternative to keep track of old chainid is to implement a smart contract based caching solution as eip-1344 proposes comes with an overall higher gas cost. as such the gas cost is simply a necessary cost for the feature. rationale the only approach available today is to specify the chain id at compile time. using this approach will result in problems after a contentious hardfork as the contract can’t accept message signed with a new chainid. the approach proposed by eip-1344 is to give access to the latest chainid. this is in itself not sufficient and pose the opposite of the problem mentioned above since as soon as a hardfork that change the chainid happens, every l2 messages signed as per eip-712 (with the previous chainid) will fails to be accepted by the contracts after the fork. that’s why in the rationale of eip-1344 it is mentioned that users need to implement/use a mechanism to verify the validity of past chainid via a trustless cache implemented via smart contract. while this works (except for a temporary gap where the immediately previous chainid is not considered valid), this is actually a required procedure for all contracts that want to accept l2 messages since without it, messages signed before an hardfork that updated the chainid would be rejected. in other words, eip-1344 expose such risk and it is easy for contract to not consider it by simply checking chainid == chain_id() without considering past chainids. indeed letting contracts access the latest chainid for l2 message verification is dangerous. the latest chainid is only the tip of the chainid history. as a changing value, the latest chainid is thus not appropriate to ensure the validity of l2 messages. users signing off-chain messages expect their messages to be valid from the time of signing and do not expect these message to be affected by a future hardfork. if the contract use the latest chainid as is for verification, the messages would be invalid as soon as a hardfork that update the chainid happens. for some applications, this will require users to resubmit a new message (think meta transaction), causing them potential loss (or some inconvenience during the hardfork transition), but for some other applications (think state channel) the whole off-chain state become inaccessible, resulting in potentially disastrous situations. in other words, we should consider all off-chain messages (with valid chainid) as part of the chain’s offchain state. the opcode proposed here, offer smart contracts a simple and safe method to ensure that the offchain state stay valid across fork. as for replay protection, the idea of considering all of the off-chain messages signed with valid chainid as part of the chain’s offchain-state means that all of these off-chain messages can be reused on the different forks which share a common chainid history (up to where they differ). this is actually an important feature since as mentioned, users expect their signed messages to be valid from the time of signing. from that time onwards these messages should be considered as part of the chain’s offchain state. a hardfork should not thus render them invalid. this is similar to how the previous on-chain state is shared between 2 hardforks. the wallets will make sure that at any time, a signing message request use the latest chainid of the chain being used. this prevent replay attack onto chain that have different chainid histories (they would not have the same latest chainid). now it is argued in the eip1344 discussion that when a contentious hardfork happen and one side of the fork decide to not update its chainid, that side of the chain would be vulnerable to replays since users will keep signing with a chainid that is also valid in the chain that forked. an issue also present in eip-1344. this is simply a natural consequence of using chainid as the only anti-replay information for l2 messages. but this can indeed be an issue if the hardfork is created by a small minority. in that case if the majority ignore the fork and do not update its chainid, then all new message from the majority chain (until they update their chainid) can be replayed on the minority-led hardfork since the majority’s current chainid is also part of the minority-led fork’s chainid history. to fix this, every message could specify the block number representing the time it was signed. the contract could then verify that chainid specified as part of that message was valid at that particular block. while eip-1344 can’t do that accurately as the caching system might leave a gap, this proposal can solve it if it is modified to return the blocknumber at which a chainid become invalid. unfortunately, this would be easy for contracts to not perform that check. and since it suffice of only one important applications to not follow this procedure to put the minority-led fork at a disadvantage, this would fail to achieve the desired goal of protecting the minority-led fork from replay. since a minority-led fork ignored by the majority means that the majority will not keep track of the messages to be submitted (state channel, …), if such fork get traction later, this would be at the expense of majority users who were not aware of it. as such this proposal assume that minority-led fork will not get traction later and thus do not require to be protected. test cases tbd implementation tbd backwards compatibility this eip is fully backwards compatible with all chains which implement eip-155 chain id domain separator for transaction signing. existing contract are not affected. similarly to eip-1344, it might be beneficial to update eip-712 (still in draft) to deal with chainid separately from the domain separator. indeed since chainid is expected to change, if the domain separator include chainid, it would have to be dynamically computed. a caching mechanism could be used by smart contract instead though. references this was previously suggested as part of eip-1344 discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: ronan sandford (@wighawag), "eip-1959: new opcode to check if a chainid is part of the history of chainids [draft]," ethereum improvement proposals, no. 1959, april 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1959. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-3440: erc-721 editions standard ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-3440: erc-721 editions standard authors nathan ginnever (@nginnever) created 2021-04-20 discussion link https://ethereum-magicians.org/t/eip-3340-nft-editions-standard-extension/6044 requires eip-712, eip-721 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases reference implementation security considerations copyright simple summary this standard addresses an extension to the erc-721 specification by allowing signatures on nfts representing works of art. this provides improved provenance by creating functionality for an artist to designate an original and signed limited-edition prints of their work. abstract erc-3440 is an erc-721 extension specifically designed to make nfts more robust for works of art. this extends the original erc-721 spec by providing the ability to designate the original and limited-edition prints with a specialized enumeration extension similar to the original 721 extension built-in. the key improvement of this extension is allowing artists to designate the limited nature of their prints and provide a signed piece of data that represents their unique signature to a given token id, much like an artist would sign a print of their work. motivation currently the link between a nft and the digital work of art is only enforced in the token metadata stored in the shared tokenuri state of a nft. while the blockchain provides an immutable record of history back to the origin of an nft, often the origin is not a key that an artist maintains as closely as they would a hand written signature. an edition is a printed replica of an original piece of art. erc-721 is not specifically designed to be used for works of art, such as digital art and music. erc-721 (nft) was originally created to handle deeds and other contracts. eventually erc-721 evolved into gaming tokens, where metadata hosted by servers may be sufficient. this proposal takes the position that we can create a more tangible link between the nft, digital art, owner, and artist. by making a concise standard for art, it will be easier for an artist to maintain a connection with the ethereum blockchain as well as their fans that purchase their tokens. the use cases for nfts have evolved into works of digital art, and there is a need to designate an original nft and printed editions with signatures in a trustless manner. erc-721 contracts may or may not be deployed by artists, and currently, the only way to understand that something is uniquely touched by an artist is to display it on 3rd party applications that assume a connection via metadata that exists on servers, external to the blockchain. this proposal helps remove that distance with readily available functionality for artists to sign their work and provides a standard for 3rd party applications to display the uniqueness of a nft for those that purchase them. the designation of limited-editions combined with immutable signatures, creates a trustlessly enforced link. this signature is accompanied by view functions that allow applications to easily display these signatures and limited-edition prints as evidence of uniqueness by showing that artists specifically used their key to designate the total supply and sign each nft. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. erc-721 compliant contracts may implement this erc for editions to provide a standard method for designating the original and limited-edition prints with signatures from the artist. implementations of erc-3440 must designate which token id is the original nft (defaulted to id 0), and which token id is a unique replica. the original print should be token id number 0 but may be assigned to a different id. the original print must only be designated once. the implementation must designate a maximum number of minted editions, after which new ids must not be printed / minted. artists may use the signing feature to sign the original or limited edition prints but this is optional. a standard message to sign is recommended to be simply a hash of the integer of the token id. signature messages must use the eip-712 standard. a contract that is compliant with erc-3440 shall implement the following abstract contract (referred to as erc3440.sol): // spdx-license-identifier: mit pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/erc721/extensions/erc721uristorage.sol"; import "@openzeppelin/contracts/utils/cryptography/ecdsa.sol"; /** * @dev erc721 token with editions extension. */ abstract contract erc3440 is erc721uristorage { // eip-712 struct eip712domain { string name; string version; uint256 chainid; address verifyingcontract; } // contents of message to be signed struct signature { address verificationaddress; // ensure the artists signs only address(this) for each piece string artist; address wallet; string contents; } // type hashes bytes32 constant eip712domain_typehash = keccak256( "eip712domain(string name,string version,uint256 chainid,address verifyingcontract)" ); bytes32 constant signature_typehash = keccak256( "signature(address verifyaddress,string artist,address wallet, string contents)" ); bytes32 public domain_separator; // optional mapping for signatures mapping (uint256 => bytes) private _signatures; // a view to display the artist's address address public artist; // a view to display the total number of prints created uint public editionsupply = 0; // a view to display which id is the original copy uint public originalid = 0; // a signed token event event signed(address indexed from, uint256 indexed tokenid); /** * @dev sets `artist` as the original artist. * @param `address _artist` the wallet of the signing artist (todo consider multiple * signers and contract signers (non-eoa) */ function _designateartist(address _artist) internal virtual { require(artist == address(0), "erc721extensions: the artist has already been set"); // if there is no special designation for the artist, set it. artist = _artist; } /** * @dev sets `tokenid as the original print` as the tokenuri of `tokenid`. * @param `uint256 tokenid` the nft id of the original print */ function _designateoriginal(uint256 _tokenid) internal virtual { require(msg.sender == artist, "erc721extensions: only the artist may designate originals"); require(_exists(_tokenid), "erc721extensions: original query for nonexistent token"); require(originalid == 0, "erc721extensions: original print has already been designated as a different id"); // if there is no special designation for the original, set it. originalid = _tokenid; } /** * @dev sets total number printed editions of the original as the tokenuri of `tokenid`. * @param `uint256 _maxeditionsupply` max supply */ function _setlimitededitions(uint256 _maxeditionsupply) internal virtual { require(msg.sender == artist, "erc721extensions: only the artist may designate max supply"); require(editionsupply == 0, "erc721extensions: max number of prints has already been created"); // if there is no max supply of prints, set it. leaving supply at 0 indicates there are no prints of the original editionsupply = _maxeditionsupply; } /** * @dev creates `tokenids` representing the printed editions. * @param `string memory _tokenuri` the metadata attached to each nft */ function _createeditions(string memory _tokenuri) internal virtual { require(msg.sender == artist, "erc721extensions: only the artist may create prints"); require(editionsupply > 0, "erc721extensions: the edition supply is not set to more than 0"); for(uint i=0; i < editionsupply; i++) { _mint(msg.sender, i); _settokenuri(i, _tokenuri); } } /** * @dev internal hashing utility * @param `signature memory _message` the signature message struct to be signed * the address of this contract is enforced in the hashing */ function _hash(signature memory _message) internal view returns (bytes32) { return keccak256(abi.encodepacked( "\x19\x01", domain_separator, keccak256(abi.encode( signature_typehash, address(this), _message.artist, _message.wallet, _message.contents )) )); } /** * @dev signs a `tokenid` representing a print. * @param `uint256 _tokenid` id of the nft being signed * @param `signature memory _message` the signed message * @param `bytes memory _signature` signature bytes created off-chain * * requirements: * * `tokenid` must exist. * * emits a {signed} event. */ function _signedition(uint256 _tokenid, signature memory _message, bytes memory _signature) internal virtual { require(msg.sender == artist, "erc721extensions: only the artist may sign their work"); require(_signatures[_tokenid].length == 0, "erc721extensions: this token is already signed"); bytes32 digest = hash(_message); address recovered = ecdsa.recover(digest, _signature); require(recovered == artist, "erc721extensions: artist signature mismatch"); _signatures[_tokenid] = _signature; emit signed(artist, _tokenid); } /** * @dev displays a signature from the artist. * @param `uint256 _tokenid` nft id to verify issigned * @returns `bytes` gets the signature stored on the token */ function getsignature(uint256 _tokenid) external view virtual returns (bytes memory) { require(_signatures[_tokenid].length != 0, "erc721extensions: no signature exists for this id"); return _signatures[_tokenid]; } /** * @dev returns `true` if the message is signed by the artist. * @param `signature memory _message` the message signed by an artist and published elsewhere * @param `bytes memory _signature` the signature on the message * @param `uint _tokenid` id of the token to be verified as being signed * @returns `bool` true if signed by artist * the artist may broadcast signature out of band that will verify on the nft */ function issigned(signature memory _message, bytes memory _signature, uint _tokenid) external view virtual returns (bool) { bytes32 messagehash = hash(_message); address _artist = ecdsa.recover(messagehash, _signature); return (_artist == artist && _equals(_signatures[_tokenid], _signature)); } /** * @dev utility function that checks if two `bytes memory` variables are equal. this is done using hashing, * which is much more gas efficient then comparing each byte individually. * equality means that: * 'self.length == other.length' * for 'n' in '[0, self.length)', 'self[n] == other[n]' */ function _equals(bytes memory _self, bytes memory _other) internal pure returns (bool equal) { if (_self.length != _other.length) { return false; } uint addr; uint addr2; uint len = _self.length; assembly { addr := add(_self, /*bytes_header_size*/32) addr2 := add(_other, /*bytes_header_size*/32) } assembly { equal := eq(keccak256(addr, len), keccak256(addr2, len)) } } } rationale a major role of nfts is to display uniqueness in digital art. provenance is a desired feature of works of art, and this standard will help improve a nft by providing a better way to verify uniqueness. taking this extra step by an artist to explicitly sign tokens provides a better connection between the artists and their work on the blockchain. artists can now retain their private key and sign messages in the future showing that the same signature is present on a unique nft. backwards compatibility this proposal combines already available 721 extensions and is backwards compatible with the erc-721 standard. test cases an example implementation including tests can be found here. reference implementation // spdx-license-identifier: mit pragma solidity ^0.8.0; import "./erc3440.sol"; /** * @dev erc721 token with editions extension. */ contract arttoken is erc3440 { /** * @dev sets `address artist` as the original artist to the account deploying the nft. */ constructor ( string memory _name, string memory _symbol, uint _numberofeditions, string memory tokenuri, uint _originalid ) erc721(_name, _symbol) { _designateartist(msg.sender); _setlimitededitions(_numberofeditions); _createeditions(tokenuri); _designateoriginal(_originalid); domain_separator = keccak256(abi.encode( eip712domain_typehash, keccak256(bytes("artist's editions")), keccak256(bytes("1")), 1, address(this) )); } /** * @dev signs a `tokenid` representing a print. */ function sign(uint256 _tokenid, signature memory _message, bytes memory _signature) public { _signedition(_tokenid, _message, _signature); } } security considerations this extension gives an artist the ability to designate an original edition, set the maximum supply of editions as well as print the editions and uses the tokenuri extension to supply a link to the art work. to minimize the risk of an artist changing this value after selling an original piece this function can only happen once. ensuring that these functions can only happen once provides consistency with uniqueness and verifiability. due to this, the reference implementation handles these features in the constructor function. an edition may only be signed once, and care should be taken that the edition is signed correctly before release of the token/s. copyright copyright and related rights waived via cc0. citation please cite this document as: nathan ginnever (@nginnever), "erc-3440: erc-721 editions standard [draft]," ethereum improvement proposals, no. 3440, april 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3440. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1922: zk-snark verifier standard ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1922: zk-snark verifier standard authors michael connor , chaitanya konda , duncan westland created 2018-09-14 discussion link https://github.com/ethereum/eips/issues/1922 requires eip-165, eip-196, eip-197 table of contents simple summary abstract motivation specification interface rationale taxonomy functions backwards compatibility test cases implementations references copyright simple summary a standard interface for “verifier” contracts which verify zk-snarks. abstract the following standard allows for the implementation of a standard contract api for the verification of zk-snarks (“zero-knowledge succinct non-interactive arguments of knowledge”), also known as “proofs”, “arguments”, or “commitments”. this standard provides basic functionality to load all necessary parameters for the verification of any zk-snark into a verifier contract, so that the proof may ultimately return a true or false response; corresponding to whether it has been verified or not verified. motivation zk-snarks are a promising area of interest for the ethereum community. key applications of zk-snarks include: private transactions private computations improved transaction scaling through proofs of “bundled” transactions a standard interface for verifying all zk-snarks will allow applications to more easily implement private transactions, private contracts, and scaling solutions; and to extract and interpret the limited information which gets emitted during zk-snark verifications. this standard was initially proposed by ey, and was inspired in particular by the requirements of businesses wishing to keep their agreements, transactions, and supply chain activities confidential—all whilst still benefiting from the commonly cited strengths of blockchains and smart contracts. :warning: todo: explain the benefits to and perspective of a consumer of information. i.e. the thing that interfaces with the standard verifier. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. terminology in this specification is used consistently with libsnark, as provided in that project’s readme. adhering contract — a verifier contract which adheres to this specification. arithmetic circuit: an abstraction of logical statements into addition and multiplication gates. public inputs: often denoted as a vector ‘x’ in zk-snarks literature, and denoted inputs in this interface. an arithmetic circuit can be thought of as taking two parameters; the public inputs, ‘x’, and a secret ‘witness’, ‘w’. this interface standardises functions which can load the inputs into an adhering contract. proof: a ‘prover’ who wants to ‘prove’ knowledge of some secret witness ‘w’ (which satisfies an arithmetic circuit), generates a proof from: the circuit’s proving key; their secret witness ‘w’; and its corresponding public inputs ‘x’. together, a pair (proof, inputs) of satisfying inputs and their corresponding proof forms a zk-snark. verification key: a ‘trusted setup’ calculation creates both a public ‘proving key’ and a public ‘verification key’ from an arithmetic circuit. this interface does not provide a method for loading a verification key onto the blockchain. an adhering contract shall be able to accept arguments of knowledge ((proof, inputs) pairs) for at least one verification key. we shall call such verification keys ‘in-scope’ verification keys. an adhering contract must be able to interpret unambiguously a unique verificationkeyid for each of its ‘in-scope’ verification keys. every erc-xxxx compliant verifier contract must implement the ercxxxx and erc165 interfaces (subject to “caveats” below): pragma solidity ^0.5.6; /// @title eip-xxxx zk-snark verifier standard /// @dev see https://github.com/eyblockchain/zksnark-verifier-standard /// note: the erc-165 identifier for this interface is 0xxxxxxxxx. /// ⚠️ todo: calculate interface identifier interface eipxxxx /* is erc165 */ { /// @notice checks the arguments of proof, through elliptic curve /// pairing functions. /// @dev /// must return `true` if proof passes all checks (i.e. the proof is /// valid). /// must return `false` if the proof does not pass all checks (i.e. if the /// proof is invalid). /// @param proof a zk-snark. /// @param inputs public inputs which accompany proof. /// @param verificationkeyid a unique identifier (known to this verifier /// contract) for the verification key to which proof corresponds. /// @return result the result of the verification calculation. true /// if proof is valid; false otherwise. function verify(uint256[] calldata proof, uint256[] calldata inputs, bytes32 verificationkeyid) external returns (bool result); } interface interface erc165 { /// @notice query if a contract implements an interface /// @param interfaceid the interface identifier, as specified in erc-165 /// @dev interface identification is specified in erc-165. this function /// uses less than 30,000 gas. /// @return `true` if the contract implements `interfaceid` and /// `interfaceid` is not 0xffffffff, `false` otherwise function supportsinterface(bytes4 interfaceid) external view returns (bool); } rationale taxonomy ⚠️ todo: add a specific reference to libsnark here, explaining the choice of variable names. :warning: todo: explain how c may not necessarily be a satisfiable arithmetic circuit of logical statements. as current, this is a limitation to certain kinds of snarks. whereas the source references also mention polynomials, and other applications. c — a satisfiable arithmetic circuit abstraction of logical statements. lambda a random number, generated at the ‘setup’ phase commonly referred to as ‘toxic waste’, because knowledge of lambda would allow an untrustworthy party to create ‘false’ proofs which would verify as ‘true’. lambda must be destroyed. pk the proving key for a particular circuit c. vk the verification key for a particular circuit c. both pk and vk are generated as a pair by some function g: (pk, vk) = g(lambda, c) note: c can be represented unambiguously by either of pk or vk. in zk-snark constructions, vk is much smaller in size than pk, so as to enable succinct verification on-chain. hence, vk is the representative of c that is ‘known’ to the contract. therefore, we can identify each circuit uniquely through some verificationkeyid, where verificationkeyid serves as a more succinct mapping to vk. w a ‘private witness’ string. a private argument to the circuit c known only to the prover, which, when combined with the inputs argument x, comprises an argument of knowledge which satisfies the circuit c. x or inputs a vector of ‘public inputs’. a public argument to the circuit c which, when combined with the private witness string w, comprises an argument of knowledge which satisfies the circuit c. pi or proof an encoded vector of values which represents the ‘prover’s’ ‘argument of knowledge’ of values w and x which satisfy the circuit c. pi = p(pk, x, w). the ultimate purpose of a verifier contract, as specified in this eip, is to verify a proof (of the form pi) through some verification function v. v(vk, x, pi) = 1, if there exists a w s.t. c(x,w)=1. v(vk, x, pi) = 0, otherwise. the verify() function of this specification serves the purpose of v; returning either true (the proof has been verified to satisfy the arithmetic circuit) or false (the proof has not been verified). functions verify the verify function forms the crux this standard. the parameters are intended to be as generic as possible, to allow for verification of any zk-snark: proof specified as uint256[]. uint256 is the most appropriate type for elliptic curve operations over a finite field. indeed, this type is used in the predominant ‘pairing library’ implementation of zk-snarks by christian reitweissner. a one-dimensional dynamic array has been chosen for several reasons: dynamic: there are several possible methods for producing a zk-snark proof, including pghr13, g16, gm17, and future methods might be developed in future. although each method may produce differently sized proof objects, a dynamic array allows for these differing sizes. array: an array has been chosen over a ‘struct’ object, because it is currently easier to pass dynamic arrays between functions in solidity. any proof ‘struct’ can be ‘flattened’ to an array and passed to the verify function. interpretation of that flattened array is the responsibility of the implemented body of the function. example implementations demonstrate that this can be achieved. one-dimensional: a one-dimensional array has been chosen over multi-dimensional array, because it is currently easier to work with one-dimensional arrays in solidity. any proof can be ‘flattened’ to a one-dimensional array and passed to the verify function. interpretation of that flattened array is the responsibility of the implemented body of the adhering contract. example implementations demonstrate that this can be achieved. inputs specified as uint256[]. uint256 is the most appropriate type for elliptic curve operations over a finite field. indeed, this type is used in the predominant ‘pairing library’ implementation of zk-snarks by christian reitweissner. the number of inputs will vary in size, depending on the number of ‘public inputs’ of the arithmetic circuit being verified against. in a similar vein to the proof parameter, a one-dimensional dynamic array is general enough to cope with any set of inputs to a zk-snark. verificationkeyid a verification key (referencing a particular arithmetic circuit) only needs to be stored on-chain once. any proof (relating to the underlying arithmetic circuit) can then be verified against that verification key. given this, it would be unnecessary (from a ‘gas cost’ point of view) to pass a duplicate of the full verification key to the verify function every time a new (proof, inputs) pair is passed in. we do however need to tell the adhering verifier contract which verification key corresponds to the (proof, inputs) pair being passed in. a verificationkeyid serves this purpose it uniquely represents a verification key as a bytes32 id. a method for uniquely assigning a verificationkeyid to a verification key is the responsibility of the implemented body of the adhering contract. backwards compatibility at the time this eip was first proposed, there was one implementation on the ethereum main net deployed by ey. this was compiled with solidity 0.4.24 for compatibility with truffle but otherwise compatible with this standard, which is presented at the latest current version of solidity. dr christian reitwiessner’s excellent example of a verifier contract and elliptic curve pairing library has been instrumental in the ethereum community’s experimentation and development of zk-snark protocols. many of the naming conventions of this eip have been kept consistent with his example. existing zk-snark compilers such as zokrates, which produce ‘verifier.sol’ contracts, do not currently produce verifier contracts which adhere to this eip specification. :warning: todo: provide a converter contract or technique which allows zokrates verifier.sol contracts to adhere with this eip. test cases truffle tests of example implementations are included in the test case repository. ⚠️ todo: reference specific test cases because there are many currently in the repository. implementations detailed example implementations and truffle tests of these example implementations are included in this repository. :warning: todo: update referenced verifier implementations so that they are ready-to-deploy or reference deployed versions of those implementations. at current, the referenced code specifically states “do not use this in production”. :warning: todo: provide reference to an implementation which interrogates a standard verifier contract that implements this standard. references :warning: todo: update references and confirm that each reference is cited (parenthetical documentation not necessary) in the text. standards erc-20 token standard. ./eip-20.md erc-165 standard interface detection. ./eip-165.md erc-173 contract ownership standard (draft). ./eip-173.md erc-196 precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128. ./eip-196.md erc-197 precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128. ./eip-197.md ethereum name service (ens). https://ens.domains rfc 2119 key words for use in rfcs to indicate requirement levels. https://www.ietf.org/rfc/rfc2119.txt educational material: zk-snarks zcash. what are zk-snarks? https://z.cash/technology/zksnarks.html vitalik buterin. zk-snarks: under the hood. https://medium.com/@vitalikbuterin/zk-snarks-under-the-hood-b33151a013f6 christian reitweissner. zk-snarks in a nutshell. https://blog.ethereum.org/2016/12/05/zksnarks-in-a-nutshell/ ben-sasson, chiesa, tromer, et. al. succinct non-interactive zero knowledge for a von neumann architecture. https://eprint.iacr.org/2013/879.pdf notable applications of zk-snarks ey. implementation of a business agreement through token commitment transactions on the ethereum mainnet. https://github.com/eyblockchain/zkpchallenge zcash. https://z.cash zcash. how transactions between shielded addresses work. https://blog.z.cash/zcash-private-transactions/ notable projects relating to zk-snarks libsnark: a c++ library for zk-snarks (“project readme)”. https://github.com/scipr-lab/libsnark zokrates: scalable privacy-preserving off-chain computations. https://www.ise.tu-berlin.de/fileadmin/fg308/publications/2018/2018_eberhardt_zokrates.pdf zokrates project repository. https://github.com/jacobeberhardt/zokrates joseph stockermans. zksnarks: driver’s ed. https://github.com/jstoxrocky/zksnarks_example christian reitweissner snarktest.solidity. https://gist.github.com/chriseth/f9be9d9391efc5beb9704255a8e2989d notable ‘alternatives’ to zk-snarks areas of ongoing zero-knowledge proof research vitalik buterin. starks. https://vitalik.ca/general/2017/11/09/starks_part_1.html bu ̈nz, bootle, boneh, et. al. bulletproofs. https://eprint.iacr.org/2017/1066.pdf range proofs. https://www.cosic.esat.kuleuven.be/ecrypt/provpriv2012/abstracts/canard.pdf apple. secure enclaves. https://developer.apple.com/documentation/security/certificate_key_and_trust_services/keys/storing_keys_in_the_secure_enclave intel software guard extensions. https://software.intel.com/en-us/sgx copyright copyright and related rights waived via cc0. citation please cite this document as: michael connor , chaitanya konda , duncan westland , "erc-1922: zk-snark verifier standard [draft]," ethereum improvement proposals, no. 1922, september 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1922. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1295: modify ethereum pow incentive structure and delay difficulty bomb ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1295: modify ethereum pow incentive structure and delay difficulty bomb authors brian venturo (@atlanticcrypto) created 2018-08-05 discussion link https://github.com/atlanticcrypto/discussion/issues/1 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary network security and overall ecosystem maturity warrants the continued incentivization of proof of work participation but may allow for a reduction in ancillary eth issuance and the delay of the difficulty bomb. this eip proposes a reduction of uncle and removal of nephew rewards while delaying the difficulty bomb with the constantinople hard fork. abstract starting with cnstntnpl_fork_blknum the client will calculate the difficulty based on a fake block number suggesting the client that the difficulty bomb is adjusting around 6 million blocks later than previously specified with the homestead fork. furthermore, uncle rewards will be adjusted and nephew rewards will be removed to eliminate excess ancillary eth issuance. the current eth block reward of 3 eth will remain constant. motivation network scalability and security are at the forefront of risks to the ethereum protocol. with great strides being made towards on and off chain scalability, the existence of an artificial throughput limiting device in the protocol is not warranted. removing the risk of reducing throughput through the initialization of the difficulty bomb is “low-hanging-fruit” to ensure continued operation at a minimum of current throughput through the next major hard fork (scheduled for late 2019). the security layer of the ethereum network is and should remain robust. incentives for continued operation of the security of the growing ecosystem are paramount. at the same time, the ancillary issuance benefits of the ethereum protocol can be adjusted to reduce the overall issuance profile. aggressively adjusting uncle and removing nephew rewards will reduce the inflationary aspect of eth issuance, while keeping the current block reward constant at 3 eth will ensure top line incentives stay in place. specification relax difficulty with fake block number for the purposes of calc_difficulty, simply replace the use of block.number, as used in the exponential ice age component, with the formula: fake_block_number = max(0, block.number 6_000_000) if block.number >= cnstntnpl_fork_blknum else block.number adjust uncle and nephew rewards if an uncle is included in a block for block.number >= cnstntnpl_fork_blknum such that block.number uncle.number = k, the uncle reward is new_uncle_reward = (3 k) * new_block_reward / 8 this is the existing pre-constantinople formula for uncle rewards, adjusted to reward 2 levels of uncles at a reduced rate. the nephew reward for block.number >= cnstntnpl_fork_blknum is new_nephew_reward = 0 this is a removal of all rewards for nephew blocks. rationale the security layer of the ethereum network is and should remain robust. incentives for continued operation of the growing ecosystem’s security are paramount. at the same time, the ancillary issuance benefits of the ethereum protocol can be adjusted to reduce the overall issuance profile. aggressively adjusting uncle and removing nephew rewards will reduce the inflationary aspect of eth issuance, while keeping the current block reward constant at 3 eth will ensure top line incentives stay in place. the difficulty bomb was instituted as a type of planned obsolescence to force the implementation of network upgrades with regular frequency. with the focus on scalability for the protocol, delaying a mechanism whereby the throughput of the network can be limited artificially, due to any circumstance, is a logical step to ensure continued minimum network operation at the current throughput level. we believe the existence of the difficulty bomb has allowed for the inclusion of protocol upgrades in forced hard-forks, and will continue to do so. through august 4th, the 2018 year to date reward issued to uncle blocks totaled over 635,000 eth. the average reward per uncle totals 2.27 eth. the year to date average uncle rate is 22.49%. using the year to date metrics, the ongoing average eth paid as an uncle reward per block is 0.51 eth plus the uncle inclusion reward of 0.021 eth (0.09375 eth * .2249), total uncle related reward per block being over 0.53 eth. with total year to date block rewards totaling approximately 3,730,000 eth, the network has paid an additional 17pct in uncle rewards. this is issuance that can be reduced while still maintaining the overall integrity and incentivization of network security. reducing the issuance of eth in rewarding uncle blocks (forked blocks caused by latency in propagation, a multi-faceted problem) should directly incentivize the investment in technologies and efficiencies to reduce block propagation latency which may lead to a reduction in network wide uncle rates, reducing ancillary issuance further. reducing the uncle rewards from the current specification to the proposed will yield two levels of ancillary eth issuance for uncles: level 1 uncle -> 0.75 eth level 2 uncle -> 0.375 eth these levels are sufficient to continue incentivizing decentralized participation, while also providing an immediate economic incentive for the upgrade of the ethereum node network and its tangential infrastructure. we believe that the eth network has been subsidizing transaction inclusion through the robust uncle reward structure since inception. we also believe that a removal of the set subsidy will create a dynamic response mechanism whereby miners and transaction senders will minimize total costs of transaction inclusion. this dynamic response structure may limit unnecessary layer 1 transaction throughput while providing incentives for layer 2 scaling solutions. the nephew reward structure should be entirely eliminated. due to current market conditions, and the likelihood of a further usd denominated price decline (50%), we believe that any top line reduction to security incentives will put the ethereum network at undue risk. unlike the time of the byzantium hard fork, current usd denominated economics for securing the ethereum network threaten the participation of the most decentralized miner community (at home miners), which we believe make up the largest proportion of the overall network hashrate. we believe eliminating this portion of the community will increase centralization and the probability of an organized network attack. for a technology so new and with so much potential, we find it extremely irresponsible to increase the likelihood of a network attack by reducing eth issuance past this proposal’s level. with a reduction to the uncle and removal of the nephew reward, ancillary eth issuance should drop (under normal market conditions, i.e. 22.49% uncle rate) by over 75pct and total eth issuance from the successful sealing and mining of valid blocks should drop over 10pct. paired with the diffusal of the difficulty bomb, this proposal strikes a balance between ensuring status quo network throughput, reducing overall eth issuance, and continuing top line incentives for investment in infrastructure and efficiencies to continue operating the ethereum network’s security layer. backwards compatibility this eip is not forward compatible and introduces backwards incompatibilities in the difficulty calculation, as well as the block, uncle and nephew reward structure. therefore, it should be included in a scheduled hardfork at a certain block number. it’s suggested to include this eip in the second metropolis hard-fork, constantinople. test cases test cases shall be created once the specification is to be accepted by the developers or implemented by the clients. implementation forthcoming. copyright copyright and related rights waived via cc0. citation please cite this document as: brian venturo (@atlanticcrypto), "eip-1295: modify ethereum pow incentive structure and delay difficulty bomb [draft]," ethereum improvement proposals, no. 1295, august 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1295. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2982: serenity phase 0 ethereum improvement proposals allcorenetworkinginterfaceercmetainformational informational eip-2982: serenity phase 0 phase 0 of the release schedule of serenity, a series of updates to ethereum a scalable, proof-of-stake consensus authors danny ryan (@djrtwo), vitalik buterin (@vbuterin) created 2020-09-15 table of contents abstract motivation scaling through sharding decentralization and economic finality through proof-of-stake specification parameters validator deposit contract beacon chain and validator mechanics issuance initial punitive parameters rationale principles the layer 1 vs layer 2 tradeoff why proof of stake why casper sharding or, why do we hate supernodes? security models why are the casper incentives set the way they are? bls signatures why 32 eth validator sizes? random sampling lmd ghost fork choice rule the proof of custody game ssz the validator lifecycle fork mechanism backwards compatibility security considerations copyright abstract this eip specifies phase 0 of serenity (eth2), a multi-phased upgrade to the consensus mechanism for ethereum mainnet. in phase 0, the existing pow chain and mechanics are entirely unaffected, while a pos chain – the beacon chain – is built in parallel to serve as the core of the upgraded consensus. in subsequent phases, the beacon chain is enhanced to support and secure the consensus of a number of parallel shard chains, ultimately incorporating current ethereum mainnet as one of those shards. at the core of the beacon chain is a proof of stake consensus mechanism called casper the friendly finality gadget (ffg) and a fork-choice rule called latest message driven greedy heaviest observed sub-tree (lmd-ghost). phase 0 is centered primarily around the mechanics and incentives of validators executing these algorithms. the detailed specifications for eth2 are contained in an independent repository from this eip, and safety and liveness proofs can be found in the combining ghost and casper paper. to avoid duplication, this eip just references relevant spec files and releases. early phases of eth2 are executed without any breaking consensus changes on current ethereum mainnet. this eip serves to document the bootstrapping of this consensus mechanism and note the path for eth2 to supplant ethereum’s current proof-of-work (pow) consensus. motivation eth2 aims to fulfill the original vision of ethereum to support an efficient, global-scale, general-purpose transactional platform while retaining high cryptoeconomic security and decentralization. today, ethereum blocks are consistently full due to increasingly high demand for decentralized applications. ever since the first serious spikes in adoption in 2017 (cryptokitties), the ethereum community has consistently and vocally demanded scaling solutions. since day 0 of ethereum, the investigation and expectation in scaling solutions has been two-pronged – scale from both layer 1 upgrades and layer 2 adoption. this eip represents the start to a multi-phased rollout of the former. scaling through sharding as the ethereum network and the applications built upon it have seen increasing usage over the past 5 years, blocks have become regularly full and the gas price market continues to climb. simple increases to the block gas-limit of the current ethereum chain are unable to account for the increase in demand of the system without inducing an unsustainably high resource burden (in the form of bandwidth, computational, and disk resources) on consumer nodes. to retain decentralization while scaling up the ethereum network, another path must be taken. to provide more scale to ethereum, while not inducing a restrictively high burden on both consumer and consensus nodes, eth2 introduces a “sharded” solution in which a number of blockchain shards – each of similar capacity to ethereum mainnet today – run in parallel under a unified consensus mechanism. the core consensus (the beacon chain) and a small number of these shards can be processed via a single consumer machine, while the aggregate of the system provides much higher capacity. decentralization and economic finality through proof-of-stake since the early days of ethereum, proof-of-stake has been a long-awaited desideratum for the following: increased decentralization of the core consensus by lowering the barrier to entry and technical requirements of participation increased cryptoeconomic security via in-protocol penalties for misbehaviour and the addition of economic finality elimination of the energy hungry mining of the current pow consensus mechanism in addition to the above, pos has synergies with the sharding scaling solution. due to the random sampling requirement of sharding, pos provides a more simple and direct access to the “active validator set” than pow and thus allows for a more direct sharded protocol construction. specification phase 0 is designed to require no breaking consensus changes to existing ethereum mainnet. instead, this is the bootstraping a new pos consensus that can, once stable, supplant the current pow consensus. phase 0 specifications are maintained in a repository independent of this eip. spec_release_version release of the specs at spec_release_commit are considered the canonical phase 0 specs for this eip. this eip provides a high level view on the phase 0 mechanisms, especially those that are relevant to ethereum mainnet (e.g. the deposit contract) and users (e.g. validator mechanics and eth2 issuance). the extended and low level details remain in the consensus-specs repository parameters parameter value spec_release_version v1.0.0 spec_release_commit 579da6d2dc734b269dbf67aa1004b54bb9449784 deposit_contract_address 0x00000000219ab540356cbb839cbe05303d7705fa min_genesis_time 1606824000 base_reward_factor 2**6 (64) inactivity_penalty_quotient 2**26 (67,108,864) proportional_slashing_multiplier 1 min_slashing_penalty_quotient 2**7 (128) note: eth2 has many more phase 0 configuration parameters but the majority are left out of this eip for brevity. validator deposit contract in phase 0, eth2 uses a contract deployed on ethereum mainnet – the deposit contract – at deposit_contract_address to onboard validators into the pos consensus of the beacon chain. to participate in the pos consensus, users submit validator deposits to the deposit contract. the beacon chain comes to consensus on the state of this contract and processes new validator deposits. this uni-directional deposit mechanism is the only technical link between the two components of the system (ethereum mainnet and beacon chain) in phase 0. beacon chain and validator mechanics users who choose to participate in eth2 consensus deposit eth collateral into the deposit contract in order to be inducted into the beacon chain validator set. from there, these validators are responsible for constructing the beacon chain (note that these consensus participants in pos are akin to miners in pow). the beacon chain is a pure pos chain that in phase 0 is primarily concerned with maintaining its own consensus and managing the registry of validators. the consensus rules define roles (e.g. block proposal, block attesting) that validators are expected to participate in; validators who perform their roles well are rewarded, and validators who perform their roles poorly or are offline are penalized. phase 0 does not yet include any eth transfer, sharding or smart contract / vm execution capabilities. in subsequent phases, additional mechanisms and validator responsibilities will be added to the beacon chain to manage the consensus of a number of parallel shard chains (“phase 1”), to integrate the existing ethereum system (“phase 1.5”) and to add full support for sharded smart contract execution (“phase 2”). issuance to incentivize validators to deposit ether collateral and participate in the eth2 consensus, we propose that rewards (in the form of ethereum’s native asset, ether) be regularly issued to consensus participants. due to the beacon chain operating in parallel to the existing pow chain in early phases of eth2, this issuance is in addition to any pow rewards until the existing chain is merged into eth2 as a shard. the amount of ether issued to validators on the beacon chain is proportional to the square root of the total ether deposited. this issuance curve was chosen as a more stable and sustainable curve to the two obvious alternatives – fixed total issuance and fixed issuance per ether staked. for a more technical discussion on this choice see here. in eth2, this curve is parameterized by base_reward_factor in the context of slot time and epoch length. below is the issuance curve as a function of ether staked, along with a table of examples for illustration. note, all figures shown are annualized. active deposits max annual validator reward* max annual eth issued* 0.5m eth 23.50% 117,527 1m eth 16.60% 166,208 2m eth 11.75% 235,052 4m eth 8.31% 332,411 8m eth 5.88% 470,104 16m eth 4.16% 664,801 32m eth 2.94% 940,167 64m eth 2.08% 1,329,603 128m eth 1.47% 1,880,334 *assuming validators are online 100% of the time and behaving optimally. suboptimal validator behavior will lead to reduced rewards and/or penalties that reduce total issuance. initial punitive parameters for pos protocols to be crypto-economically secure, in-protocol penalties are required. small offline penalties incentivize validator liveness, whereas (potentially) much larger penalties provide protocol security in the event of tail-risk scenarios. specifically, the following significant penalties exist: inactivity leak: an offline penalty that increases each epoch is applied to validators during extended times of no finality (e.g. if one-third or more are offline or not on the canonical chain). this ensures the chain can eventually regain finality even under catastrophic conditions. slashing: a penalty applied to validators that sign explicitly malicious messages that could lead to the construction and finalization of two conflicting chains (e.g. two blocks or attestations in the same slot). this penalty is designed to scale up in proportion to the number of slashable validators in the same time period such that if a critical number (wrt chain safety) of slashings have occurred, validators are maximally punished. for the initial launch of phase 0, the parameters defining the magnitude of these penalties – inactivity_penalty_quotient, proportional_slashing_multiplier, and min_slashing_penalty_quotient – have been tuned to be less punitive than their final intended values. this provides a more forgiving environment for early validators and client software in an effort to encourage validation in this early, higher technical-risk stage. inactivity_penalty_quotient is configured initially to four times its final value. this results in a slower inactivity leak during times of non-finality, which means the chain is less responsive to such an event. if there is an extended time of non-finality during the early months of eth2, it is far more likely to be due to technical issues with client software rather than some sort of global catastrophic event. proportional_slashing_multiplier is configured initially to one-third of its final value. this results in a lower accountable safety margin in the event of an attack. if any validators are slashed in the early months of eth2, it is far more likely to be the result of user mismanagement of keys and/or issues with client software than an organized attack. min_slashing_penalty_quotient configured initially to four times its final value. this results in a lower guaranteed minimum penalty for a slashable offense and thus reduces the baseline punitive incentive to keep an individual validator’s system secure. as with proportional_slashing_multiplier, slashings during the early months of eth2 are far more likely to be due to user mismanagement, or issues with client software, than an organized attack. rationale principles simplicity: especially since cryptoeconomic proof of stake and quadratic sharding are inherently complex, the protocol should strive for maximum simplicity in its decisions as much as possible. this is important because it (i) minimizes development costs, (ii) reduces risk of unforeseen security issues, and (iii) allows protocol designers to more easily convince users that parameter choices are legitimate. when complexity is unavoidable to achieve a given level of functionality, the preference order for where the complexity goes is: layer 2 protocols > client implementations > protocol spec. long-term stability: the low levels of the protocol should ideally be built so that there is no need to change them for a decade or longer, and any needed innovation can happen on higher levels (client implementations or layer 2 protocols). sufficiency: it should be fundamentally possible to build as many classes of applications as possible on top of the protocol. defense in depth: the protocol should continue to work as well as possible under a variety of possible security assumptions (eg. regarding network latency, fault count, the motivations of users) full light-client verifiability: given some assumptions (eg. network latency, bounds on attacker budget, 1-of-n or few-of-n honest minority), a client verifying a small fixed amount of data (ideally just the beacon chain) should be able to gain indirect assurance that all of the data in the full system is available and valid, even under a 51% attack (note: this is a form of defense-in-depth but it’s important enough to be separate) the layer 1 vs layer 2 tradeoff the ethereum roadmap uses a mixed layer 1 / layer 2 approach. we focus on serving a particular type of layer 2 (rollups) because it’s the only kind of layer 2 that both inherits the security of layer 1 and provides scaling of general-purpose applications. however, rollups come at a cost: they require some on-chain data per transaction, and so a blockchain with really high capacity rollups must be able to handle a still quite high amount of data bandwidth. so make this more feasible, we are implementing on scalable data layer technologies, particularly data availability sampling. the reason to not take a pure layer 2 approach is that pure layer 2 scaling can only be done either with trust-based solutions (not desirable), or with channels or plasma (which have inherent limitations and cannot support the full evm. the reason to not take a pure layer 1 approach is to enable more room for experimentation in execution layers, and allow the base protocol to be simpler and have less intensive governance. why proof of stake in short: no need to consume large quantities of electricity in order to secure a blockchain (e.g. it’s estimated that both bitcoin and ethereum burn over $1 million worth of electricity and hardware costs per day as part of their consensus mechanism). because of the lack of high electricity consumption, there is not as much need to issue as many new coins in order to motivate participants to keep participating in the network. it may theoretically even be possible to have negative net issuance, where a portion of transaction fees is “burned” and so the supply goes down over time. proof of stake opens the door to a wider array of techniques that use game-theoretic mechanism design in order to better discourage centralized cartels from forming and, if they do form, from acting in ways that are harmful to the network (e.g. like selfish mining in proof of work). reduced centralization risks, as economies of scale are much less of an issue. $10 million of coins will get you exactly 10 times higher returns than $1 million of coins, without any additional disproportionate gains because at the higher level you can afford better mass-production equipment, which is an advantage for proof-of-work. ability to use economic penalties to make various forms of 51% attacks vastly more expensive to carry out than proof of work to paraphrase vlad zamfir, “it’s as though your asic farm burned down if you participated in a 51% attack”. why casper there are currently three major schools of proof of stake consensus algorithm: nakamoto-inspired (peercoin, nxt, ouroboros…) pbft-inspired (tendermint, casper ffg, hotstuff…) cbc casper within the latter two camps, there is also the question of whether and how to use security deposits and slashing (nakamoto-inspired algorithms are incompatible with non-trivial slashing). all three are superior to proof of work, but we want to defend our own approach. slashing ethereum 2.0 uses a slashing mechanism where a validator that is detected to have misbehaved can be penalized, in the best case ~1% but in the worst case up to its entire deposit. we defend our use of slashing as follows: raising the cost of attack: we want to be able to make a hard claim that a 51% attack on a proof of stake blockchain forces the attacker to incur a very large amount of expense (think: hundreds of millions of dollars worth of coins) that get burned, and any attack can be recovered from quickly. this makes the attack/defense calculus very unfavorable for attackers, and in fact makes attacks potentially counterproductive, because the disruption to service is outweighed by price gains to legitimate coin holders. overcoming the validator’s dilemma: the most realistic immediate way for nodes to start to deviate from “honest” behavior is laziness (ie. not validating things that one should be validating, signing everything just in case, etc). see the validator’s dilemma paper (luu et al., cc by) for theoretical reasoning and the bitcoin spv mining fork for examples of this happening and leading to very harmful consequences in the wild. having very large penalties for self-contradicting or for signing incorrect things helps to alleviate this. a more subtle instance of (2) can be seen as follows. in july 2019 a validator on cosmos was slashed for signing two conflicting blocks. an investigation revealed that this happened because that validator was running a primary and a backup node (to ensure that one of the two going offline would not prevent them from getting rewards) and the two were accidentally turned on at the same time, leading to them contradicting each other. if it became standard practice to have a primary and backup node, then an attacker could partition the network and get the primaries and the backups of all the validators to commit to different blocks, and thereby lead to two conflicting blocks being finalized. slashing penalties help to heavily disincentivize this practice, reducing the risk of such a scenario taking place. choice of consensus algorithm only the bft-inspired and cbc schools of consensus algorithm have a notion of finality, where a block is confirmed in such a way that a large portion (1/3 in bft-inspired, 1/4 in cbc) of validators would need to misbehave and get slashed for that block to get reverted in favor of some conflicting block; nakamoto-inspired (ie. longest-chain-rule) consensus algorithms have no way of achieving finality in this sense. note that finality requires a (super)majority of validators being online, but this is a requirement of the sharding mechanism already, as it requires 2/3 of a randomly sampled committee of validators to sign off on a crosslink for that crosslink to be accepted. our choice of casper ffg was simply a matter of it being the simplest algorithm available at the time that part of the protocol was being finalized. details are still subject to long-term change; in particular, we are actively exploring solutions to achieve single slot finality. sharding or, why do we hate supernodes? the main alternative to sharding for layer-1 scaling is the use of supernodes simply requiring every consensus node to have a powerful server so that it can individually process every transaction. supernode-based scaling is convenient because it is simple to implement: it works just the same way blockchains do now, except that more software-engineering work is required to build things in a way that is more parallelizable. our main objections to this approach are as follows: pool centralization risk: in a supernode-based system, running a node has a high fixed cost, so far fewer users can participate. this is usually rebutted with “well consensus in most pow and pos coins is dominated by 5-20 pools anyway, and the pools will be able to run nodes just fine”. however, this response ignores the risk of centralization pressure even between pools that can afford it. if the fixed cost of running a validator is significant relative to the returns, then larger pools will be able to offer smaller fees than smaller ones and this could lead to smaller pools being pushed out or feeling pressure to merge. in a sharded system, on the other hand, validators with more eth need to verify more transactions, so costs are not fixed. aws centralization risk: in a supernode-based system, home staking is infeasible and so it’s more likely that most staking will happen inside cloud computing environments, of which there are only a few options to choose from. this creates a single point of failure. reduced censorship resistance: making it impossible to participate in consensus without high computation+bandwidth requirements makes detection and censorship of validators easier. scalability: as transaction throughput increases, in a supernode-based system the above risks increase, whereas sharded systems can more easily handle the increased load. these centralization risks are also why we are not attempting to achieve super-low-latency (<1s) of the blockchain, instead opting for (relatively!) conservative numbers. instead, ethereum is taking an approach where each validator is only assigned to process a small portion of all data. only validators staking large amounts of eth (think: tens of thousands or more) are required to process the entire data in the chain. note that there is a possible middle-ground in sharding design where block production is centralized but (i) block verification is decentralized and (ii) there exist “bypass channels” where users can send transactions and block producers are forced to include them, so even a monopoly producer cannot censor. we are actively considering sharding designs that lean somewhat in this direction to increase simplicity so that scaling can be deployed faster, though if desired even within this spec it’s possible to run distributed builders and avoid centralization even there. security models it’s commonly assumed that blockchains depend on an “honest majority” assumption for their security: that >=50% of participants will faithfully follow a prescribed protocol, even forgoing opportunities to defect for their own personal interest. in reality, (i) an honest majority model is unrealistic, with participants being “lazy” and signing off on blocks without validating them (see the validator’s dilemma paper and the bitcoin spv mining fork) being a very common form of defection, but fortunately (ii) blockchains maintain many or all of their security properties under much harsher models, and it’s really important to preserve those extra guarantees. a common harsher model is the uncoordinated rational majority model, which states that participants act in their own self-interest, but no more than some percentage (eg. 23.21% in simple pow chains) are cooperating with each other. an even harsher model is the worst-case model where there is a single actor that controls more than 50% of hashpower or stake, and the question becomes: can we, even under that scenario, force the attacker to have to pay a very high cost to break the chain’s guarantees? what guarantees can we unconditionally preserve? slashing in proof of stake chains accomplishes the first objective. in non-sharded chains, every node verifying every block accomplishes the second objective for two specific guarantees: (i) that the longest chain is valid, and (ii) that the longest chain is available. a major challenge in sharding is getting the same two properties without requiring each node to verify the full chain. our defense-in-depth approach with sharding accomplishes just that. the core idea is to combine together random committee sampling, proof of custody, fraud proofs, data availability sampling (das) and eventually zk-snarks, to allow clients to detect and reject invalid or unavailable chains without downloading and verifying all of the data, even if the invalid chains are supported by a majority of all proof of stake validators. censorship of transactions can potentially be detected by clients in a consensus-preserving way, but this research has not yet been incorporated into the ethereum roadmap. here is the current expected security properties expressed in a table: network delay <3s network delay 3s 6 min network delay > 6 min >2/3 validators honest perfect operation imperfect but acceptable operation. no rigorous proof of liveness, but liveness expected in practice. likely intermittent liveness failures, no safety failures >2/3 validators rational, <1/3 coordinated perfect operation imperfect but acceptable operation, heightened centralization risk likely intermittent liveness failures, no safety failures, very high centralization risk 51% attacker can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains can revert finality or censor, but at high cost; cannot force through invalid or unavailable chains can revert finality or censor; cannot force through invalid or unavailable chains why are the casper incentives set the way they are? base rewards during each epoch, every validator is expected to make an “attestation”, a signature that expresses that validator’s opinion on what the head of the chain is. there is a reward for having one’s attestation included, with four components (called “duties”): reward for the attestation getting included at all reward for the attestation specifying the correct epoch checkpoint reward for the attestation specifying the correct chain head reward for correctly participating in sync committee signatures note also that mixed into these duties is a timeliness requirement: your attestation has to be included within a certain time to be eligible for the rewards, and for the “correct head” duty that time limit is 1 slot. for each duty, the actual reward is computed as follows. if: $r = b * \frac{nom}{den}$ equals the base reward multiplied by the fraction $\frac{nom}{den}$ that corresponds to that particular duty $p$ is the portion of validators that did the desired action then: any validator that fulfilled the dury gets a reward of $r * p$ any validator that did not fulfill the duty gets a penalty $-r$ the purpose of this “collective reward” scheme where “if anyone performs better, everyone performs better” is to bound griefing factors (see this paper for one description of griefing factors and why they are important). the base reward $b$ is itself calculated as $k * \frac{d_i}{\sqrt{\sum_{j=1}^{n} d_j}}$ where $d_1 … d_n$ are deposit sizes and $k$ is a constant; this is a halfway compromise between two common models, (i) fixed reward rate, ie. $k * d_i$, and (ii) fixed total reward, ie. $k * \frac{d_i}{\sum_{j=1}^{n} d_j}$. the main argument against (i) is that it imposes too much uncertainty on the network of two kinds: uncertainty of the total level of issuance, and uncertainty of the total level of deposits (as if a fixed reward rate is set too low then almost no one will participate, threatening the network, and if a rate is set too high then very many validators will participate, leading to unexpectedly high issuance). the main argument against (ii) is greater vulnerability to discouragement attacks (again see the discouragement attacks paper). the inverse-square-root approach compromises between the two and avoids the worst consequences of each one. when an attestation gets a reward, the proposer gets a fraction of that reward. this is to encourage proposers to listen well for messages and accept as many as possible. note also that the rewards are designed to be forgiving to validators who are offline often: being offline 1% of the time only sacrifices about 1.6% of your reward. this is also to promote decentralization: the goal of a decentralized system is to create a reliable whole out of unreliable parts, so we should not be trying to force each individual node to be extremely reliable. inactivity leak if the chain fails to finalize for $tsf > 4$ epochs ($tsf$ = “time since finality”), then a penalty is added so that the maximum possible reward is zero (validators performing imperfectly get penalized), and a second penalty component is added, proportional to $tsf$ (that is, the longer the chain has not finalized, the higher the per-epoch penalty for being offline). this ensures that if more than 1/3 of validators drop off, validators that are not online get penalized much more heavily, and the total penalty goes up quadratically over time. this has three consequences: penalizes being offline much more heavily in the case where you being offline is actually preventing blocks from being finalized serves the goals of being an anti-correlation penalty (see section below) ensures that if more than 1/3 do go offline, eventually the portion online goes back up to 2/3 because of the declining deposits of the offline validators with the current parametrization, if blocks stop being finalized, validators lose 1% of their deposits after 2.6 days, 10% after 8.4 days, and 50% after 21 days. this means for example that if 50% of validators drop offline, blocks will start finalizing again after 21 days. slashing and anti-correlation penalties if a validator is caught violating the casper ffg slashing condition, they get penalized a portion of their deposit equal to three times the portion of validators that were penalized around the same time as them (specifically, between 18 days before they were penalized and roughly the time they withdrew). this is motivated by several goals: a validator misbehaving is only really bad for the network if they misbehave at the same time as many other validators, so it makes sense to punish them more in that case it heavily penalizes actual attacks, but applies very light penalties to single isolated failures that are likely to be honest mistakes it ensures that smaller validators take on less risk than larger validators (as in the normal case, a large validator would be the only one failing at the same time as themselves) it creates a disincentive against everyone joining the largest pool bls signatures bls signatures are used because of their aggregation-friendliness: any two signatures $s_1$ and $s_2$ of a message $m$ signed by keys $k_1$ and $k_2$ (corresponding pubkeys $k_1 = g * k_1$ and $k_2 = g * k_2$ where $g$ is the generator of the elliptic curve) can simply be aggregated by elliptic curve point addition: $s_1 + s_2$, which verifies against the public key $k_1 + k_2$. this allows many thousands of signatures to be aggregated, with the marginal cost of one signature being one bit of data (to express that a particular public key is present in the aggregate signature) and one elliptic curve addition for computation. note that bls signatures of this form are vulnerable to rogue key attacks: if you see that other validators have already published public keys $k_1 … k_n$, then you can generate a private key $r$ and publish a public key $g * r k_1 … k_n$. the aggregate public key would simply be $g * r$, so you would be able to make a signature that verifies against the combined public key by yourself. the standard way to get around this is to require a proof of possession: basically, a signature of a message (that depends on the public key, and that would normally not be signed) that verifies against the public key by itself (ie. $sign(message=h’(k), key=k)$ for privkey $k$ and pubkey $k$, where $h’$ is a hash function). this ensures that you personally control the private key connected to the public key that you publish. we use the signature of a deposit message (which specifies the signing key but also other important data such as the withdrawal key) as a proof of possession. why 32 eth validator sizes? any bft consensus algorithm with accountable fault tolerance (ie. if two conflicting blocks get finalized you can identify which 1/3 of nodes were responsible) must have all validators participate, and furthermore for technical reasons you need two rounds of every validator participating to finalize a message. this leads to the decentralization / finality time / overhead tradeoff: if $n$ is the number of validators in a network, $f$ is the time to finalize a block, and $\omega$ is the overhead in messages per second, then we have: \[\omega \ge \frac{2 * n}{f}\] for example, if we are ok with an overhead of 10 messages per second, then a 10000-node network could only have a finality time of at least 2000 seconds (~33 minutes). in ethereum’s case, if we assume a total eth supply of $\approx 2^{27}$ eth, then with 32 eth deposit sizes, there are at most $2^{22}$ validators (and that’s if everyone validates; in general we expect ~10x less eth validating). with a finality time of 2 epochs (2 * 32 * 12 = 768 seconds), that implies a max overhead of $\frac{2^{22}}{768} \approx 5461$ messages per second. we can tolerate such high overhead due to bls aggregation reducing the marginal size of each signature to 1 bit and the marginal verification complexity to one elliptic curve addition. 32 slots is a safe minimum for another reason: if an attacker manipulates the randomness used for proposer selection, this number still provides enough space to ensure that there will be at least one honest proposer in each epoch, which is sufficient to ensure blocks keep finalizing. our calculations suggest that current levels of overhead are acceptable, but higher levels would make running a node too difficult. finally, the validator deposit size is ideal for shard crosslinking (see below). random sampling seed selection the seed used for randomness is updated every block by “mixing in” (ie. seed , mario , defifofum (@defifofum), elliott green (@elliott-green) created 2022-09-08 requires eip-721 table of contents abstract motivation use cases specification rationale terms vesting functions timestamps limitation of scope extension possibilities backwards compatibility test cases reference implementation security considerations copyright abstract a non-fungible token (nft) standard used to vest tokens (erc-20 or otherwise) over a vesting release curve. the following standard allows for the implementation of a standard api for nft based contracts that hold and represent the vested and locked properties of any underlying token (erc-20 or otherwise) that is emitted to the nft holder. this standard is an extension of the erc-721 token that provides basic functionality for creating vesting nfts, claiming the tokens and reading vesting curve properties. motivation vesting contracts, including timelock contracts, lack a standard and unified interface, which results in diverse implementations of such contracts. standardizing such contracts into a single interface would allow for the creation of an ecosystem of onand off-chain tooling around these contracts. in addition, liquid vesting in the form of non-fungible assets can prove to be a huge improvement over traditional simple agreement for future tokens (safts) or externally owned account (eoa)-based vesting as it enables transferability and the ability to attach metadata similar to the existing functionality offered by with traditional nfts. such a standard will not only provide a much-needed erc-20 token lock standard, but will also enable the creation of secondary marketplaces tailored for semi-liquid safts. this standard also allows for a variety of different vesting curves to be implement easily. these curves could represent: linear vesting cliff vesting exponential vesting custom deterministic vesting use cases a framework to release tokens over a set period of time that can be used to build many kinds of nft financial products such as bonds, treasury bills, and many others. replicating saft contracts in a standardized form of semi-liquid vesting nft assets. safts are generally off-chain, while today’s on-chain versions are mainly address-based, which makes distributing vesting shares to many representatives difficult. standardization simplifies this convoluted process. providing a path for the standardization of vesting and token timelock contracts. there are many such contracts in the wild and most of them differ in both interface and implementation. nft marketplaces dedicated to vesting nfts. whole new sets of interfaces and analytics could be created from a common standard for token vesting nfts. integrating vesting nfts into services like safe wallet. a standard would mean services like safe wallet could more easily and uniformly support interactions with these types of contracts inside of a multisig contract. enable standardized fundraising implementations and general fundraising that sell vesting tokens (eg. safts) in a more transparent manner. allows tools, front-end apps, aggregators, etc. to show a more holistic view of the vesting tokens and the properties available to users. currently, every project needs to write their own visualization of the vesting schedule of their vesting assets. if this is standardized, third-party tools could be developed to aggregate all vesting nfts from all projects for the user, display their schedules and allow the user to take aggregated vesting actions. such tooling can easily discover compliance through the erc-165 supportsinterface(interfaceid) check. makes it easier for a single wrapping implementation to be used across all vesting standards that defines multiple recipients, periodic renting of vesting tokens etc. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/erc721/ierc721.sol"; /** * @title non-fungible vesting token standard. * @notice a non-fungible token standard used to vest erc-20 tokens over a vesting release curve * scheduled using timestamps. * @dev because this standard relies on timestamps for the vesting schedule, it's important to keep track of the * tokens claimed per vesting nft so that a user cannot withdraw more tokens than allotted for a specific vesting nft. * @custom:interface-id 0xbd3a202b */ interface ierc5725 is ierc721 { /** * this event is emitted when the payout is claimed through the claim function. * @param tokenid the nft tokenid of the assets being claimed. * @param recipient the address which is receiving the payout. * @param claimamount the amount of tokens being claimed. */ event payoutclaimed(uint256 indexed tokenid, address indexed recipient, uint256 claimamount); /** * this event is emitted when an `owner` sets an address to manage token claims for all tokens. * @param owner the address setting a manager to manage all tokens. * @param spender the address being permitted to manage all tokens. * @param approved a boolean indicating whether the spender is approved to claim for all tokens. */ event claimapprovalforall(address indexed owner, address indexed spender, bool approved); /** * this event is emitted when an `owner` sets an address to manage token claims for a `tokenid`. * @param owner the `owner` of `tokenid`. * @param spender the address being permitted to manage a tokenid. * @param tokenid the unique identifier of the token being managed. * @param approved a boolean indicating whether the spender is approved to claim for `tokenid`. */ event claimapproval(address indexed owner, address indexed spender, uint256 indexed tokenid, bool approved); /** * @notice claim the pending payout for the nft. * @dev must grant the claimablepayout value at the time of claim being called to `msg.sender`. * must revert if not called by the token owner or approved users. * must emit payoutclaimed. * should revert if there is nothing to claim. * @param tokenid the nft token id. */ function claim(uint256 tokenid) external; /** * @notice number of tokens for the nft which have been claimed at the current timestamp. * @param tokenid the nft token id. * @return payout the total amount of payout tokens claimed for this nft. */ function claimedpayout(uint256 tokenid) external view returns (uint256 payout); /** * @notice number of tokens for the nft which can be claimed at the current timestamp. * @dev it is recommended that this is calculated as the `vestedpayout()` subtracted from `payoutclaimed()`. * @param tokenid the nft token id. * @return payout the amount of unlocked payout tokens for the nft which have not yet been claimed. */ function claimablepayout(uint256 tokenid) external view returns (uint256 payout); /** * @notice total amount of tokens which have been vested at the current timestamp. * this number also includes vested tokens which have been claimed. * @dev it is recommended that this function calls `vestedpayoutattime` * with `block.timestamp` as the `timestamp` parameter. * @param tokenid the nft token id. * @return payout total amount of tokens which have been vested at the current timestamp. */ function vestedpayout(uint256 tokenid) external view returns (uint256 payout); /** * @notice total amount of vested tokens at the provided timestamp. * this number also includes vested tokens which have been claimed. * @dev `timestamp` may be both in the future and in the past. * zero must be returned if the timestamp is before the token was minted. * @param tokenid the nft token id. * @param timestamp the timestamp to check on, can be both in the past and the future. * @return payout total amount of tokens which have been vested at the provided timestamp. */ function vestedpayoutattime(uint256 tokenid, uint256 timestamp) external view returns (uint256 payout); /** * @notice number of tokens for an nft which are currently vesting. * @dev the sum of vestedpayout and vestingpayout should always be the total payout. * @param tokenid the nft token id. * @return payout the number of tokens for the nft which are vesting until a future date. */ function vestingpayout(uint256 tokenid) external view returns (uint256 payout); /** * @notice the start and end timestamps for the vesting of the provided nft. * must return the timestamp where no further increase in vestedpayout occurs for `vestingend`. * @param tokenid the nft token id. * @return vestingstart the beginning of the vesting as a unix timestamp. * @return vestingend the ending of the vesting as a unix timestamp. */ function vestingperiod(uint256 tokenid) external view returns (uint256 vestingstart, uint256 vestingend); /** * @notice token which is used to pay out the vesting claims. * @param tokenid the nft token id. * @return token the token which is used to pay out the vesting claims. */ function payouttoken(uint256 tokenid) external view returns (address token); /** * @notice sets a global `operator` with permission to manage all tokens owned by the current `msg.sender`. * @param operator the address to let manage all tokens. * @param approved a boolean indicating whether the spender is approved to claim for all tokens. */ function setclaimapprovalforall(address operator, bool approved) external; /** * @notice sets a tokenid `operator` with permission to manage a single `tokenid` owned by the `msg.sender`. * @param operator the address to let manage a single `tokenid`. * @param tokenid the `tokenid` to be managed. * @param approved a boolean indicating whether the spender is approved to claim for all tokens. */ function setclaimapproval(address operator, bool approved, uint256 tokenid) external; /** * @notice returns true if `owner` has set `operator` to manage all `tokenid`s. * @param owner the owner allowing `operator` to manage all `tokenid`s. * @param operator the address who is given permission to spend tokens on behalf of the `owner`. */ function isclaimapprovedforall(address owner, address operator) external view returns (bool isclaimapproved); /** * @notice returns the operating address for a `tokenid`. * if `tokenid` is not managed, then returns the zero address. * @param tokenid the nft `tokenid` to query for a `tokenid` manager. */ function getclaimapproved(uint256 tokenid) external view returns (address operator); } rationale terms these are base terms used around the specification which function names and definitions are based on. vesting: tokens which a vesting nft is vesting until a future date. vested: total amount of tokens a vesting nft has vested. claimable: amount of vested tokens which can be unlocked. claimed: total amount of tokens unlocked from a vesting nft. timestamp: the unix timestamp (seconds) representation of dates used for vesting. vesting functions vestingpayout + vestedpayout vestingpayout(uint256 tokenid) and vestedpayout(uint256 tokenid) add up to the total number of tokens which can be claimed by the end of of the vesting schedule. this is also equal to vestedpayoutattime(uint256 tokenid, uint256 timestamp) with type(uint256).max as the timestamp. the rationale for this is to guarantee that the tokens vested and tokens vesting are always in sync. the intent is that the vesting curves created are deterministic across the vestingperiod. this creates useful opportunities for integration with these nfts. for example: a vesting schedule can be iterated through and a vesting curve could be visualized, either on-chain or off-chain. vestedpayout vs claimedpayout & claimablepayout vestedpayout claimedpayout claimablepayout = lockedpayout vestedpayout(uint256 tokenid) provides the total amount of payout tokens which have vested including claimedpayout(uint256 tokenid). claimedpayout(uint256 tokenid) provides the total amount of payout tokens which have been unlocked at the current timestamp. claimablepayout(uint256 tokenid) provides the amount of payout tokens which can be unlocked at the current timestamp. the rationale for providing three functions is to support a number of features: the return of vestedpayout(uint256 tokenid) will always match the return of vestedpayoutattime(uint256 tokenid, uint256 timestamp) with block.timestamp as the timestamp. claimablepayout(uint256 tokenid) can be used to easily see the current payout unlock amount and allow for unlock cliffs by returning zero until a timestamp has been passed. claimedpayout(uint256 tokenid) is helpful to see tokens unlocked from an nft and it is also necessary for the calculation of vested-but-locked payout tokens: vestedpayout claimedpayout claimablepayout = lockedpayout. this would depend on how the vesting curves are configured by the an implementation of this standard. vestedpayoutattime(uint256 tokenid, uint256 timestamp) provides functionality to iterate through the vestingperiod(uint256 tokenid) and provide a visual of the release curve. the intent is that release curves are created which makes vestedpayoutattime(uint256 tokenid, uint256 timestamp) deterministic. timestamps generally in solidity development it is advised against using block.timestamp as a state dependant variable as the timestamp of a block can be manipulated by a miner. the choice to use a timestamp over a block is to allow the interface to work across multiple ethereum virtual machine (evm) compatible networks which generally have different block times. block proposal with a significantly fabricated timestamp will generally be dropped by all node implementations which makes the window for abuse negligible. the timestamp makes cross chain integration easy, but internally, the reference implementation keeps track of the token payout per vesting nft to ensure that excess tokens alloted by the vesting terms cannot be claimed. limitation of scope historical claims: while historical vesting schedules can be determined on-chain with vestedpayoutattime(uint256 tokenid, uint256 timestamp), historical claims would need to be calculated through historical transaction data. most likely querying for payoutclaimed events to build a historical graph. extension possibilities these feature are not supported by the standard as is, but the standard could be extended to support these more advanced features. custom vesting curves: this standard intends on returning deterministic vesting values given nft tokenid and a timestamp as inputs. this is intentional as it provides for flexibility in how the vesting curves work under the hood which doesn’t constrain projects who intend on building a complex smart contract vesting architecture. nft rentals: further complex defi tools can be created if vesting nfts could be rented. this is done intentionally to keep the base standard simple. these features can and likely will be added through extensions of this standard. backwards compatibility the vesting nft standard is meant to be fully backwards compatible with any current erc-721 integrations and marketplaces. the vesting nft standard also supports erc-165 interface detection for detecting eip-721 compatibility, as well as vesting nft compatibility. test cases the reference vesting nft repository includes tests written in hardhat. reference implementation a reference implementation of this eip can be found in erc-5725 assets. security considerations timestamps vesting schedules are based on timestamps. as such, it’s important to keep track of the number of tokens which have been claimed and to not give out more tokens than alloted for a specific vesting nft. vestedpayoutattime(tokenid, type(uint256).max), for example, must return the total payout for a given tokenid approvals when an erc-721 approval is made on a vesting nft, the operator would have the rights to transfer the vesting nft to themselves and then claim the vested tokens. when a erc-5725 approval is made on a vesting nft, the operator would have the rights to claim the vested tokens, but not transfer the nft away from the owner. copyright copyright and related rights waived via cc0. citation please cite this document as: apeguru (@apegurus), marco de vries , mario , defifofum (@defifofum), elliott green (@elliott-green), "erc-5725: transferable vesting nft," ethereum improvement proposals, no. 5725, september 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5725. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-214: new opcode staticcall ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-214: new opcode staticcall authors vitalik buterin , christian reitwiessner created 2017-02-13 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary to increase smart contract security, this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). abstract this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present). any opcode that attempts to perform such a modification (see below for details) will result in an exception instead of performing the modification. motivation currently, there is no restriction about what a called contract can do, as long as the computation can be performed with the amount of gas provided. this poses certain difficulties about smart contract engineers; after a regular call, unless you know the called contract, you cannot make any assumptions about the state of the contracts. furthermore, because you cannot know the order of transactions before they are confirmed by miners, not even an outside observer can be sure about that in all cases. this eip adds a way to call other contracts and restrict what they can do in the simplest way. it can be safely assumed that the state of all accounts is the same before and after a static call. specification introduce a new static flag to the virtual machine. this flag is set to false initially. its value is always copied to sub-calls with an exception for the new opcode below. opcode: 0xfa. staticcall functions equivalently to a call, except it takes only 6 arguments (the “value” argument is not included and taken to be zero), and calls the child with the static flag set to true for the execution of the child. once this call returns, the flag is reset to its value before the call. any attempts to make state-changing operations inside an execution instance with static set to true will instead throw an exception. these operations include create, create2, log0, log1, log2, log3, log4, sstore, and selfdestruct. they also include call with a non-zero value. as an exception, callcode is not considered state-changing, even with a non-zero value. rationale this allows contracts to make calls that are clearly non-state-changing, reassuring developers and reviewers that re-entrancy bugs or other problems cannot possibly arise from that particular call; it is a pure function that returns an output and does nothing else. this may also make purely functional hlls easier to implement. backwards compatibility this proposal adds a new opcode but does not modify the behaviour of other opcodes and thus is backwards compatible for old contracts that do not use the new opcode and are not called via the new opcode. test cases to be written. implementation copyright copyright and related rights waived via cc0. citation please cite this document as: vitalik buterin , christian reitwiessner , "eip-214: new opcode staticcall," ethereum improvement proposals, no. 214, february 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-214. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5982: role-based access control ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: erc erc-5982: role-based access control an interface for role-based access control for smart contracts. authors zainan victor zhou (@xinbenlv) created 2022-11-15 requires eip-165, eip-5750 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip defines an interface for role-based access control for smart contracts. roles are defined as byte32. the interface specifies how to read, grant, create and destroy roles. it specifies the sense of role power in the format of its ability to call a given method identified by bytes4 method selector. it also specifies how metadata of roles are represented. motivation there are many ways to establish access control for privileged actions. one common pattern is “role-based” access control, where one or more users are assigned to one or more “roles,” which grant access to privileged actions. this pattern is more secure and flexible than ownership-based access control since it allows for many people to be granted permissions according to the principle of least privilege. 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. interfaces of reference is described as followed: interface ierc_acl_core { function hasrole(bytes32 role, address account) external view returns (bool); function grantrole(bytes32 role, address account) external; function revokerole(bytes32 role, address account) external; } interface ierc_acl_general { event rolegranted(address indexed grantor, bytes32 indexed role, address indexed grantee, bytes _data); event rolerevoked(address indexed revoker, bytes32 indexed role, address indexed revokee, bytes _data); event rolecreated(address indexed rolegrantor, bytes32 role, bytes32 adminofrole, string name, string desc, string uri, bytes32 calldata _data); event roledestroyed(address indexed roledestroyer, bytes32 role, bytes32 calldata _data); event rolepowerset(address indexed rolepowersetter, bytes32 role, bytes4 methods, bytes calldata _data); function grantrole(bytes32 role, address account, bytes calldata _data) external; function revokerole(bytes32 role, address account, bytes calldata _data) external; function createrole(bytes32 role, bytes32 adminofrole, string name, string desc, string uri, bytes32 calldata _data) external; function destroyrole(bytes32 role, bytes32 calldata _data) external; function setrolepower(bytes32 role, bytes4 methods, bytes calldata _data) view external returns(bool); function hasrole(bytes32 role, address account, bytes calldata _data) external view returns (bool); function cangrantrole(bytes32 grantor, bytes32 grantee, bytes calldata _data) view external returns(bool); function canrevokerole(bytes32 revoker, bytes32 revokee, address account, bytes calldata _data) view external returns(bool); function canexecute(bytes32 executor, bytes4 methods, bytes32 calldata payload, bytes calldata _data) view external returns(bool); } interface ierc_acl_metadata { function rolename(bytes32) external view returns(string); function roledescription(bytes32) external view returns(string); function roleuri(bytes32) external view returns(string); } compliant contracts must implement ierc_acl_core it is recommended for compliant contracts to implement the optional extension ierc_acl_general. compliant contracts may implement the optional extension ierc_acl_metadata. a role in a compliant smart contract is represented in the format of bytes32. it’s recommended the value of such role is computed as a keccak256 hash of a string of the role name, in this format: bytes32 role = keccak256(""). such as bytes32 role = keccak256("minter"). compliant contracts should implement erc-165 identifier. rationale the names and parameters of methods in ierc_acl_core are chosen to allow backward compatibility with openzeppelin’s implementation. the methods in ierc_acl_general conform to erc-5750 to allow extension. the method of renouncerole was not adopted, consolidating with revokerole to simplify interface. backwards compatibility needs discussion. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: zainan victor zhou (@xinbenlv), "erc-5982: role-based access control [draft]," ethereum improvement proposals, no. 5982, november 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5982. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3155: evm trace specification ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3155: evm trace specification authors martin holst swende (@holiman), marius van der wijden (@mariusvanderwijden) created 2020-12-07 discussion link https://ethereum-magicians.org/t/eip-3155-create-evm-trace-specification/5007 table of contents simple summary motivation specification datatypes output summary and error handling rationale backwards compatibility clients test cases implementation security considerations copyright simple summary introduce a new json standard for evm traces during execution of state tests. motivation the ethereum virtual machine executes all smart contract code on ethereum. in order to debug smart contracts and state tests better, a common format was introduced to log every execution step of the evm. this format was implemented by go-ethereum, parity, 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 eip has multiple objectives: 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 eip in all major clients allows us to create meaningful differential fuzzers that fuzz evm implementations for the mainnet and all upcoming hardforks. it also helps finding differences in execution quickly in the case of a chain split. this eip will enable users to create better differential fuzzing infrastructure to compare the evm implementations of all major ethereum 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-ethereums evm 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 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 hex-number amount of global gas refunded memsize number size of memory array 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 returnstack array of hex-numbers array of values, stack of the called function 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, returnstack, memory) must be initialized to empty arrays (“stack”:[],) not to null. if the cut will not output 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 eip. 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 some summerical 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 optionalfields: | name | type | explanation | |—|—|—| | time | number | time in nanoseconds needed to execute the transaction | | fork | string | name of the fork rules used for execution | {"stateroot":"0xd4c577737f5d20207d338c360c42d3af78de54812720e3339f7b27293ef195b7","output":"","gasused":"0x3","successful":"true","time":141485} rationale this eip is largely based on the previous non-official documentation for evm 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 eip is fully backward compatible with ethereum as it only introduces a better tracing infrastructure that is optional for clients to implement. clients this eip is fully backward compatible with go-ethereum. openethereum, besu and nethermind clients would have to change their json output of openethereum-evm evmtool 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 ~/go/src/github.com/ethereum/go-ethereum/build/bin/evm --code 604080536040604055604060006040600060025afa6040f3 --json run {"pc":0,"op":96,"gas":"0x2540be400","gascost":"0x3","memory":"0x","memsize":0,"stack":[],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":2,"op":128,"gas":"0x2540be3fd","gascost":"0x3","memory":"0x","memsize":0,"stack":["0x40"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"dup1","error":""} {"pc":3,"op":83,"gas":"0x2540be3fa","gascost":"0xc","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40","0x40"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"mstore8","error":""} {"pc":4,"op":96,"gas":"0x2540be3ee","gascost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":[],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":6,"op":96,"gas":"0x2540be3eb","gascost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":8,"op":85,"gas":"0x2540be3e8","gascost":"0x4e20","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40","0x40"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"sstore","error":""} {"pc":9,"op":96,"gas":"0x2540b95c8","gascost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":[],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":11,"op":96,"gas":"0x2540b95c5","gascost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":13,"op":96,"gas":"0x2540b95c2","gascost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40","0x0"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":15,"op":96,"gas":"0x2540b95bf","gascost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40","0x0","0x40"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":17,"op":96,"gas":"0x2540b95bc","gascost":"0x3","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40","0x0","0x40","0x0"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"push1","error":""} {"pc":19,"op":90,"gas":"0x2540b95b9","gascost":"0x2","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40","0x0","0x40","0x0","0x2"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"gas","error":""} {"pc":20,"op":250,"gas":"0x2540b95b7","gascost":"0x24abb676c","memory":"0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x40","0x0","0x40","0x0","0x2","0x2540b95b7"],"returnstack":[],"returndata":"0x","depth":1,"refund":0,"opname":"staticcall","error":""} {"pc":21,"op":96,"gas":"0x2540b92a7","gascost":"0x3","memory":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b00000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x1"],"returnstack":[],"returndata":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b","depth":1,"refund":0,"opname":"push1","error":""} {"pc":23,"op":243,"gas":"0x2540b92a4","gascost":"0x0","memory":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b00000000000000000000000000000000000000000000000000000000000000004000000000000000000000000000000000000000000000000000000000000000","memsize":96,"stack":["0x1","0x40"],"returnstack":[],"returndata":"0xf5a5fd42d16a20302798ef6ed309979b43003d2320d9f0e8ea9831a92759fb4b","depth":1,"refund":0,"opname":"return","error":""} {"stateroot":"2eef130ec61805516c1f050720b520619787704a5dd826a39aeefb850f83acfd", "output":"40","gasused":"0x515c","time":350855} implementation implementation in go-ethereum implementation in openethereum implementation in besu implementation in nethermind 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. citation please cite this document as: martin holst swende (@holiman), marius van der wijden (@mariusvanderwijden), "eip-3155: evm trace specification [draft]," ethereum improvement proposals, no. 3155, december 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3155. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5501: rental & delegation nft eip-721 extension ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5501: rental & delegation nft eip-721 extension adds a conditional time-limited user role to eip-721. this role can be delegated or borrowed. authors jan smrža (@smrza), david rábel (@rabeles11), tomáš janča , jan bureš (@johnyx89), dobbylabs (@dobbylabs) created 2022-08-18 discussion link https://ethereum-magicians.org/t/eip-tbd-rental-delegation-nft-erc-721-extension/10441 requires eip-165, eip-721, eip-4400, eip-4907 table of contents abstract motivation specification rationale name ownership retention balance and enumerable extensions terminable extension security backwards compatibility test cases reference implementation security considerations copyright abstract the following standard proposes an additional user role for eip-721. this role grants the permission to use the nft with no ability to transfer or set users. it has an expiry and a flag if the token is borrowed or not. owner can delegate the nft for usage to hot wallets or lend the nft. if the token is borrowed, not even the owner can change the user until the status expires or both parties agree to terminate. this way, it is possible to keep both roles active at the same time. motivation collectibles, gaming assets, metaverse, event tickets, music, video, domains, real item representation are several among many nft use cases. with eip-721 only the owner can reap the benefits. however, with most of the utilities it would be beneficial to distinguish between the token owner and its user. for instance music or movies could be rented. metaverse lands could be delegated for usage. the two reasons why to set the user are: delegation assign user to your hot wallet to interact with applications securely. in this case, the owner can change the user at any time. renting this use case comes with additional requirements. it is needed to terminate the loan once the established lending period is over. this is provided by expires of the user. it is also necessary to protect the borrower against resetting their status by the owner. thus, isborrowed check must be implemented to disable the option to set the user before the contract expires. the most common use cases for having an additional user role are: delegation for security reasons. gaming would you like to try a game (or particular gaming assets) but are you unsure whether or not you will like it? rent assets first. guilds keep the owner of the nfts as the multisig wallet and set the user to a hot wallet with shared private keys among your guild members. events distinguish between ownerof and userof. each role has a different access. social differentiate between roles for different rooms. for example owner has read + write access while userof has read access only. this proposal is a follow up on eip-4400 and eip-4907 and introduces additional upgrades for lending and borrowing which include: nft stays in owner’s wallet during rental period listing and sale of nft without termination of the rent claiming owner benefits during rental period building the standard with additional isborrowed check now allows to create rental marketplaces which can set the user of nft without the necessary staking mechanism. with current standards if a token is not staked during the rental period, the owner can simply terminate the loan by setting the user repeatedly. this is taken care of by disabling the function if the token is borrowed which in turn is providing the owner additional benefits. they can keep the token tied to their wallet, meaning they can still receive airdrops, claim free mints based on token ownership or otherwise use the nft provided by third-party services for owners. they can also keep the nft listed for sale. receiving airdrops or free mints was previously possible but the owner was completely reliant on the implementation of rental marketplaces and their discretion. decentralized applications can now differentiate between ownerof and userof while both statuses can coexist. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. every compliant contract must implement the ierc5501 interface. this extension is optional for eip-721 contracts. /** * @title ierc5501: rental & delegation nft eip-721 extension * @notice the eip-165 identifier for this interface is 0xf808ec37. */ interface ierc5501 /* is ierc721 */ { /** * @dev emitted when the user of an nft is modified. */ event updateuser(uint256 indexed _tokenid, address indexed _user, uint64 _expires, bool _isborrowed); /** * @notice set the user info of an nft. * @dev user address cannot be zero address. * only approved operator or nft owner can set the user. * if nft is borrowed, the user info cannot be changed until user status expires. * @param _tokenid uint256 id of the token to set user info for * @param _user address of the new user * @param _expires unix timestamp when user info expires * @param _isborrowed flag whether or not the nft is borrowed */ function setuser(uint256 _tokenid, address _user, uint64 _expires, bool _isborrowed) external; /** * @notice get the user address of an nft. * @dev reverts if user is not set. * @param _tokenid uint256 id of the token to get the user address for * @return address user address for this nft */ function userof(uint256 _tokenid) external view returns (address); /** * @notice get the user expires of an nft. * @param _tokenid uint256 id of the token to get the user expires for * @return uint64 user expires for this nft */ function userexpires(uint256 _tokenid) external view returns (uint64); /** * @notice get the user isborrowed of an nft. * @param _tokenid uint256 id of the token to get the user isborrowed for * @return bool user isborrowed for this nft */ function userisborrowed(uint256 _tokenid) external view returns (bool); } every contract implementing the ierc5501 interface is free to define the permissions of a user. however, user must not be considered an owner. they must not be able to execute transfers and approvals. furthermore, setuser must be blocked from executing if userisborrowed returns true and userexpires is larger than or equal to block.timestamp. the updateuser event must be emitted when a user is changed. the setuser(uint256 _tokenid, address _user, uint64 _expires, bool _isborrowed) function should revert unless the msg.sender is the owner or an approved operator. it must revert if a token is borrowed and status has not expired yet. it may be public or external. the userof(uint256 _tokenid) function should revert if user is not set or expired. the userexpires(uint256 _tokenid) function returns a timestamp when user status expires. the userisborrowed(uint256 _tokenid) function returns whether nft is borrowed or not. the supportsinterface function must return true when called with 0xf808ec37. on every transfer, the user must be reset if the token is not borrowed. if the token is borrowed the user must stay the same. the balance extension is optional. this gives the option to query the number of tokens a user has. /** * @title ierc5501balance * extension for erc5501 which adds userbalanceof to query how many tokens address is userof. * @notice the eip-165 identifier for this interface is 0x0cb22289. */ interface ierc5501balance /* is ierc5501 */{ /** * @notice count of all nfts assigned to a user. * @dev reverts if user is zero address. * @param _user an address for which to query the balance * @return uint256 the number of nfts the user has */ function userbalanceof(address _user) external view returns (uint256); } the userbalanceof(address _user) function should revert for zero address. the enumerable extension is optional. this allows to iterate over user balance. /** * @title ierc5501enumerable * this extension for erc5501 adds the option to iterate over user tokens. * @notice the eip-165 identifier for this interface is 0x1d350ef8. */ interface ierc5501enumerable /* is ierc5501balance, ierc5501 */ { /** * @notice enumerate nfts assigned to a user. * @dev reverts if user is zero address or _index >= userbalanceof(_owner). * @param _user an address to iterate over its tokens * @return uint256 the token id for given index assigned to _user */ function tokenofuserbyindex(address _user, uint256 _index) external view returns (uint256); } the tokenofuserbyindex(address _user, uint256 _index) function should revert for zero address and throw if the index is larger than or equal to user balance. the terminable extension is optional. this allows terminating the rent early if both parties agree. /** * @title ierc5501terminable * this extension for erc5501 adds the option to terminate borrowing if both parties agree. * @notice the eip-165 identifier for this interface is 0x6a26417e. */ interface ierc5501terminable /* is ierc5501 */ { /** * @dev emitted when one party from borrowing contract approves termination of agreement. * @param _islender true for lender, false for borrower */ event agreetoterminateborrow(uint256 indexed _tokenid, address indexed _party, bool _islender); /** * @dev emitted when agreements to terminate borrow are reset. */ event resetterminationagreements(uint256 indexed _tokenid); /** * @dev emitted when borrow of token id is terminated. */ event terminateborrow(uint256 indexed _tokenid, address indexed _lender, address indexed _borrower, address _caller); /** * @notice agree to terminate a borrowing. * @dev lender must be ownerof token id. borrower must be userof token id. * if lender and borrower are the same, set termination agreement for both at once. * @param _tokenid uint256 id of the token to set termination info for */ function setborrowtermination(uint256 _tokenid) external; /** * @notice get if it is possible to terminate a borrow agreement. * @param _tokenid uint256 id of the token to get termination info for * @return bool, bool first indicates lender agrees, second indicates borrower agrees */ function getborrowtermination(uint256 _tokenid) external view returns (bool, bool); /** * @notice terminate a borrow if both parties agreed. * @dev both parties must have agreed, otherwise revert. * @param _tokenid uint256 id of the token to terminate borrow of */ function terminateborrow(uint256 _tokenid) external; } the agreetoterminateborrow event must be emitted when either the lender or borrower agrees to terminate the rent. the resetterminationagreements event must be emitted when a token is borrowed and transferred or setuser and terminateborrow functions are called. the terminateborrow event must be emitted when the rent is terminated. the setborrowtermination(uint256 _tokenid). it must set an agreement from either party whichever calls the function. if the lender and borrower are the same address, it must assign an agreement for both parties at once. the getborrowtermination(uint256 _tokenid) returns if agreements from both parties are true or false. the terminateborrow(uint256 _tokenid) function may be called by anyone. it must revert if both agreements to terminate are not true. this function should change the isborrowed flag from true to false. on every transfer, the termination agreements from either party must be reset if the token is borrowed. rationale the main factors influencing this standard are: eip-4400 and eip-4907 allow lending and borrowing without the necessary stake or overcollateralization while owner retains ownership leave the delegation option available keep the number of functions in the interfaces to a minimum while achieving desired functionality modularize additional extensions to let developers choose what they need for their project name the name for the additional role has been chosen to fit the purpose and to keep compatibility with eip-4907. ownership retention many collections offer their owners airdrops or free minting of various tokens. this is essentially broken if the owner is lending a token by staking it into a contract (unless the contract is implementing a way to claim at least airdropped tokens). applications can also provide different access and benefits to owner and user roles in their ecosystem. balance and enumerable extensions these have been chosen as optional extensions due to the complexity of implementation based on the fact that balance is less once user status expires and there is no immediate on-chain transaction to evaluate that. in both userbalanceof and tokenofuserbyindex functions there must be a way to determine whether or not user status has expired. terminable extension if the owner mistakenly sets a user with borrow status and expires to a large value they would essentially be blocked from setting the user ever again. the problem is addressed by this extension if both parties agree to terminate the user status. security once applications adopt the user role, it is possible to delegate ownership to hot wallet and interact with them with no fear of connecting to malicious websites. backwards compatibility this standard is compatible with current eip-721 by adding an extension function set. the new functions introduced are similar to existing functions in eip-721 which guarantees easy adoption by developers and applications. this standard also shares similarities to eip-4907 considering user role and its expiry which means applications will be able to determine the user if either of the standards is used. test cases test cases can be found in the reference implementation: main contract balance extension enumerable extension terminable extension scenario combined of all extensions reference implementation the reference implementation is available here: main contract balance extension enumerable extension terminable extension solution combined of all extensions security considerations developers implementing this standard and applications must consider all the permissions they give to users and owners. since owner and user are both active roles at the same time, double-spending problem must be avoided. balance extension must be implemented in such a way which will not cause any gas problems. marketplaces should let users know if a token listed for sale is borrowed or not. copyright copyright and related rights waived via cc0. citation please cite this document as: jan smrža (@smrza), david rábel (@rabeles11), tomáš janča , jan bureš (@johnyx89), dobbylabs (@dobbylabs), "erc-5501: rental & delegation nft eip-721 extension [draft]," ethereum improvement proposals, no. 5501, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5501. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1962: ec arithmetic and pairings with runtime definitions ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1962: ec arithmetic and pairings with runtime definitions authors alex vlasov (@shamatar) created 2019-04-22 discussion link https://ethereum-magicians.org/t/generalised-precompile-for-elliptic-curve-arithmetics-and-pairings-working-group/3208/2 requires eip-1109 table of contents simple summary abstract motivation specification possible simplifications rationale this precompile and eip 1109 backwards compatibility test cases implementation preliminary benchmarks copyright simple summary this proposal is an extension and formalization of eip-1829 with an inclusion of pairings. eip-1109 is required due to low cost of some operations compared to the staticcall opcode (more information in the corresponding section below). abstract this eip proposes a new precompile to bring cryptographic functionality desired for privacy and scaling solutions. functionality of such precompile will require the following: implementation the following operations over elliptic curves in the weierstrass form with curve parameters such as base field, a, b coefficients defined in runtime: point addition multiplication of a single point over a scalar multiexponentiation implementation pairing operation over elliptic curves from the following “families” with parameters such as base field, extension tower structure, coefficients defined in runtime: bls12 bn mnt4/6 (ate pairing) full functionality of the precompile is described below in specification section. motivation there is a pending proposal to implement base elliptic curve arithmetic is covered by eip-1829 and will allow to implement various privacy-preserving protocols with a reasonable gas costs per operation. pairings are an important extension for basic arithmetic and so this new precompile is proposed with the following benefits: extended set of curves will be available to allow ethereum users to choose their security parameters and required functionality. generic approach of this precompile will allow ethereum users to experiment with newly found curves of their choice and new constructions constructions without waiting for new forks. ec arithmetic is indeed re-implemented in this precompile, but it’s strictly required. most of the pairing-based protocols still need to perform standard ec multiplications or additions and thus such operations must be available on generic set of curves. gas costs this eip is designed to estimate gas-cost of performed operation as early as possible during the call and base if solely on specified parameters and operation type. this is a strict requirement for any precompile to allow ethereum nodes to efficiently reject transactions and operations as early as possible. functionality of this newly proposed precompile is different from eip-1829 in the following aspects: operation on arbitrary-length modulus (up to some upper-limit) for a base field and scalar field of the curve pairing operations are introduced different abi due to variable parameter length specification if block.number >= xxxxx, define a set of 10 new precompiles with an addresses [0x.., 0x.., ...] and the following functionality. addition of points on the curve defined over base field multiplication of a point on the curve defined over base field multiexponentiation for n pairs of (scalar, point) on the curve defined over base field addition of points on the curve defined over quadratic or cubic extension of the base field multiplication of a point on the curve defined over quadratic or cubic extension of the base field multiexponentiation for n pairs of (scalar, point) on the curve defined over quadratic or cubic extension of the base field pairing operation on the curve of bls12 family pairing operation on the curve of bn family pairing operation on the curve of mnt4 family pairing operation on the curve of mnt6 family due to actuve development of the precompile and a lot of ongoing changes there is a single source of truth. it covers binary interface, gas schedule, integration guide for existing implementations. possible simplifications due to high complexity of the proposed operations in the aspects of implementation, debugging and evaluation of the factors for gas costs it may be appropriate to either limit the set of curves at the moment of acceptance to some list and then extend it. another approach (if it’s technically possible) would be to have the “whilelist” contract that can be updated without consensus changes (w/o fork). in the case of limited set of curve the following set is proposed as a minimal: bn254 curve from the current version of ethereum bn curve from dizk with 2^32 roots of unity bls12-381 bls12-377 from zexe with large number of roots of unity mnt4/6 cycle from the original paper. it’s not too secure, but may give some freedom for experiments. mnt4/6 cycle from coda if performance allows set of cp generated curves that would allow embedding of bls12-377 and may be some bn curve that would have large power of two divisor for both base field and scalar field modulus (example of cp curve for bls12-377 can be found in zexe). rationale only the largest design decisions will be covered: while there is no arithmetic over the scalar field (which is modulo size of the main group) of the curve, it’s required for gas estimation purposes. multiexponentiation is a separate operation due to large cost saving there are no point decompressions due to impossibility to get universal gas estimation of square root operation. for a limited number of “good” cases prices would be too different, so specifying the “worst case” is expensive and inefficient, while introduction of another level if complexity into already complicated gas costs formula is not worth is. this precompile and eip 1109 while there is no strict requirement of eip 1109 for functionality, here is an example why it would be desired: bls12-381 curve, 381 bit modulus, 255 bit scalar field, no native arithmetic is available in evm for this point addition would take 5000ns (quite overestimated) point multiplication would take roughly 150000ns crude gas schedule 15 mgas/second from ecrecover precompile point addition would cost 75 gas, with staticcall adding another 700 point multiplication would cost 2250 gas one should also add the cost of memory allocation that is at least 1 + 1 + 48 + 48 + 48 + 1 + 32 + 2*48 + 2*48 = 371 byte that is around 12 native ethereum “words” and will require extra 36 gas (with negligible price for memory extension) based on these quite crude estimations one can see that staticcall price will dominate the total cost (in case of addition) or bring significant overhead (in case of multiplication operation) in case of calls to this precompile. backwards compatibility this change is not backwards compatible and requires hard fork to be activated. functionality of the new precompile itself does not affect any existing functionality of ethereum or evm. this precompile may serve as a complete replacement of the current set of ecadd, ecmul and pairing check precompiles (0x06, 0x07, 0x08) test cases test cases are the part of the implementation with a link below. implementation there is an ongoing implementation effort here. right now: non-pairing operations are implemented and tested. bls12 family is completed and tested for bls12-381 and bls12-377 curves. bn family is completed and tested with bn254 curve. cocks-pinch method curve is tested for k=6 curve from zexe. preliminary benchmarks cp6 in benchmarks is a cocks-pinch method curve that embeds bls12-377. machine: core i7, 2.9 ghz. multiexponentiation benchmarks take 100 pairs (generator, random scalar) as input. due to the same “base” it may be not too representative benchmark and will be updated. test pairings::bls12::tests::bench_bls12_381_pairing ... bench: 2,348,317 ns/iter (+/605,340) test pairings::cp::tests::bench_cp6_pairing ... bench: 86,328,825 ns/iter (+/11,802,073) test tests::bench_addition_bn254 ... bench: 388 ns/iter (+/73) test tests::bench_doubling_bn254 ... bench: 187 ns/iter (+/4) test tests::bench_field_inverse ... bench: 2,478 ns/iter (+/167) test tests::bench_field_mont_inverse ... bench: 2,356 ns/iter (+/51) test tests::bench_multiplication_bn254 ... bench: 81,744 ns/iter (+/6,984) test tests::bench_multiplication_bn254_into_affine ... bench: 81,925 ns/iter (+/3,323) test tests::bench_multiplication_bn254_into_affine_wnaf ... bench: 74,716 ns/iter (+/4,076) test tests::bench_naive_multiexp_bn254 ... bench: 10,659,911 ns/iter (+/559,790) test tests::bench_peppinger_bn254 ... bench: 2,678,743 ns/iter (+/148,914) test tests::bench_wnaf_multiexp_bn254 ... bench: 9,161,281 ns/iter (+/456,137) copyright copyright and related rights waived via cc0. citation please cite this document as: alex vlasov (@shamatar), "eip-1962: ec arithmetic and pairings with runtime definitions [draft]," ethereum improvement proposals, no. 1962, april 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1962. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6953: network upgrade activation triggers ethereum improvement proposals allcorenetworkinginterfaceercmetainformational informational eip-6953: network upgrade activation triggers exhaustive list of network upgrade activation mechanisms authors tim beiko (@timbeiko) created 2023-04-28 requires eip-2982, eip-3675, eip-6122 table of contents abstract motivation specification proof-of-work network upgrades beacon chain launch beacon chain upgrades the merge: paris upgrade post-merge upgrades rationale blocks and epochs terminal total difficulty timestamps security considerations copyright abstract this eip outlines the various network upgrade activation triggers used on ethereum over time, from the proof-of-work era to the first post-merge network upgrade, shanghai/capella, across both the execution and consensus layers. motivation this eip aims to provide users and developers with a single source of truth for understanding the various upgrade activation patterns used throughout ethereum’s history. it does not aim to be a comprehensive, ongoing record, of upgrades and their activations mechanism. readers should assume that future upgrades use the mechanism described in the post merge upgrades section, unless this eip is superceded by another one. specification proof-of-work network upgrades during the proof-of-work era, network upgrades on ethereum were triggered based on specific block numbers. the following upgrades followed this pattern: upgrade name activation block number frontier 1 frontier thawing 200000 homestead 1150000 dao fork 1920000 tangerine whistle 2463000 spurious dragon 2675000 byzantium 4370000 constantinople 7280000 petersburg 7280000 istanbul 9069000 muir glacier 9200000 berlin 12244000 london 12965000 arrow glacier 13773000 gray glacier 15050000 beacon chain launch the beacon chain was launched following a set of conditions detailed in eip-2982. the launch was activated once all the following conditions were met: the beacon chain deposit contract received at least 524288 eth from 16384 validators. the min_genesis_time timestamp of 1606824000 (dec 1, 2020) had been exceeded. a genesis_delay of 604800 seconds had passed since the minimum validator count was exceeded. beacon chain upgrades beacon chain upgrades are activated at specific epochs. the following upgrades followed this pattern: upgrade name activation epoch altair 74240 bellatrix 144896 the merge: paris upgrade the paris upgrade, the execution layer portion of “the merge,” was triggered by a proof-of-work total difficulty value of 58750000000000000000000, as specified in eip-3675. note that the activation of the bellatrix upgrade on the beacon chain was a pre-requisite for the paris upgrade to successfully activate on the proof-of-work chain. post-merge upgrades after the merge, network upgrades are triggered at an epoch on the consensus layer (cl), which ideally maps to an historical roots accumulator boundary (i.e., a multiple of 7192 epochs). the epoch’s corresponding timestamp, rather than a block number, is then used on the execution layer (el) as the activation trigger. the following upgrades followed this pattern: upgrade name activation epoch activation timestamp capella (cl) 194048 shanghai (el) 1681338455 note that epoch 194048 happened at timestamp 1681338455. in other words, the upgrades activated simultaneously on both the execution and consensus layers, even though they each used a different constant to trigger it. additionally, the use of timestamps on the execution layer resulted in changes to how nodes’ fork_hash and fork_next values are calculated. these are described in eip-6122 rationale blocks and epochs blocks and epochs serve as natural trigger points for upgrades, as they represent the levels at which state transitions occur on ethereum. terminal total difficulty for the terminal total difficulty mechanism, the rationale can be found in eip-3675. timestamps due to the possibility of missed slots on the beacon chain, the execution layer cannot rely solely on block numbers to trigger upgrades in sync with the consensus layer. timestamps are guaranteed to map to a specific epoch, and in their unix representation, timestamps will always be greater than the block numbers previously used. this allows for a reliable method to trigger upgrades on the execution layer post-merge, while also ensuring that a post-merge upgrade based on a timestamp can never use a value that is considered lower than the last block-triggered upgrade. security considerations none. copyright copyright and related rights waived via cc0. citation please cite this document as: tim beiko (@timbeiko), "eip-6953: network upgrade activation triggers," ethereum improvement proposals, no. 6953, april 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6953. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-4488: transaction calldata gas cost reduction with total calldata limit ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-4488: transaction calldata gas cost reduction with total calldata limit greatly decreases the gas cost of transaction calldata and simultaneously caps total transaction calldata in a block authors vitalik buterin (@vbuterin), ansgar dietrichs (@adietrichs) created 2021-11-23 discussion link https://ethereum-magicians.org/t/eip-4488-transaction-calldata-gas-cost-reduction-with-total-calldata-limit/7555 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract decrease transaction calldata gas cost, and add a limit of how much total transaction calldata can be in a block. motivation rollups are in the short and medium term, and possibly the long term, the only trustless scaling solution for ethereum. transaction fees on l1 have been very high for months and there is greater urgency in doing anything required to help facilitate an ecosystem-wide move to rollups. rollups are significantly reducing fees for many ethereum users: optimism and arbitrum frequently provide fees that are ~3-8x lower than the ethereum base layer itself, and zk rollups, which have better data compression and can avoid including signatures, have fees ~40-100x lower than the base layer. however, even these fees are too expensive for many users. the long-term solution to the long-term inadequacy of rollups by themselves has always been data sharding, which would add ~1-2 mb/sec of dedicated data space for rollups to the chain. however, data sharding will still take a considerable amount of time to finish implementing and deploying. hence, a short-term solution to further cut costs for rollups, and to incentivize an ecosystem-wide transition to a rollup-centric ethereum, is desired. this eip presents a quick-to-implement short-term solution that also mitigates security risks. specification parameter value new_calldata_gas_cost 3 base_max_calldata_per_block 1,048,576 calldata_per_tx_stipend 300 reduce the gas cost of transaction calldata to new_calldata_gas_cost per byte, regardless of whether the byte is zero or nonzero. add a rule that a block is only valid if sum(len(tx.calldata) for tx in block.txs) <= base_max_calldata_per_block + len(block.txs) * calldata_per_tx_stipend. rationale a natural alternative proposal is to decrease new_calldata_gas_cost without adding a limit. however, this presents a security concern: today, the average block size is 60-90 kb, but the maximum block size is 30m / 16 = 1,875,000 bytes (plus about a kilobyte of block and tx overhead). simply decreasing the calldata gas cost from 16 to 3 would increase the maximum block size to 10m bytes. this would push the ethereum p2p networking layer to unprecedented levels of strain and risk breaking the network; some previous live tests of ~500 kb blocks a few years ago had already taken down a few bootstrap nodes. the decrease-cost-and-cap proposal achieves most of the benefits of the decrease, as rollups are unlikely to dominate ethereum block space in the short term future and so 1.5 mb will be sufficient, while preventing most of the security risk. historically, the ethereum protocol community has been suspicious of multi-dimensional resource limit rules (in this case, gas and calldata) because such rules greatly increase the complexity of the block packing problem that proposers (today miners, post-merge validators) need to solve. today, proposers can generate blocks with near-optimal fee revenue by simply choosing transactions in highest-to-lowest order of priority fee. in a multi-dimensional world, proposers would have to deal with multi-dimensional constraints. multi-dimensional knapsack problems are much more complicated than the single-dimensional equivalent, and well-optimized proprietary implementations built by pools may well outperform default open source implementations. today, there are two key reasons why this is less of a problem than before: eip-1559 means that, at least most of the time, the problem that block proposers are solving is not a knapsack problem. rather, block proposers are simply including all the transactions they can find with sufficient base fee and priority fee. hence, naive algorithms will also frequently generate close-to-optimal results. the existence of sophisticated proprietary strategies for miner extractable value (mev) extraction means that decentralized optimal block production is already in the medium and long term a lost cause. research is instead going into solutions that separate away the specialization-friendly task of block body generation from the role of a validator (“proposer/builder separation”). instead of being a fundamental change, two-dimensional knapsack problems today would be merely “yet another” mev opportunity. hence, it’s worth rethinking the historical opposition to multi-dimensional resource limits and considering them as a pragmatic way to simultaneously achieve moderate scalability gains while retaining security. additionally, the stipend mechanism makes the two-dimensional optimization problem even less of an issue in practice. 90% of all transactions (sample taken from blocks 13500000, 13501000 ... 13529000) have <300 bytes of calldata. hence, if a naive transaction selection algorithm overfills the calldata of a block that the proposer is creating, the proposer will still be able to keep adding transactions from 90% of their mempool. backwards compatibility this is a backwards incompatible gas repricing that requires a scheduled network upgrade. users will be able to continue operating with no changes. miners will be able to continue operating with no changes except for a rule to stop adding new transactions into a block when the total calldata size reaches the maximum. however, there are pragmatic heuristics that they could add to achieve closer-to-optimal returns in such cases: for example, if a block fills up to the size limit, they could repeatedly remove the last data-heavy transaction and replace it with as many data-light transactions as possible, until doing so is no longer profitable. security considerations the burst data capacity of the chain does not increase as a result of this proposal (in fact, it slightly decreases). however, the average data capacity will increase. this means that the storage requirements of history-storing will go up. a worst-case scenario would be a theoretical long-run maximum of ~1,262,861 bytes per 12 sec slot, or ~3.0 tb per year. we recommend eip-4444 or some similar history expiry proposal be implemented either at the same time or soon after this eip to mitigate this risk. copyright copyright and related rights waived via cc0. citation please cite this document as: vitalik buterin (@vbuterin), ansgar dietrichs (@adietrichs), "eip-4488: transaction calldata gas cost reduction with total calldata limit [draft]," ethereum improvement proposals, no. 4488, november 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4488. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7506: trusted hint registry ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7506: trusted hint registry a system for managing on-chain metadata, enabling verification of ecosystem claims. authors philipp bolte (@strumswell), dennis von der bey (@dennisvonderbey), lauritz leifermann (@lleifermann) created 2023-08-31 discussion link https://ethereum-magicians.org/t/eip-trusted-hint-registry/15615 requires eip-712 table of contents abstract motivation specification definitions interface meta transactions trust anchor via ens rationale backwards compatibility security considerations meta transactions rights management governance copyright abstract this eip standardizes a system for managing on-chain metadata (hints), enabling claim interpretation, reliability, and verification. it structures these hints within defined namespaces and lists, enabling structured organization and retrieval, as well as permissioned write access. the system permits namespace owners to delegate hint management tasks, enhancing operational flexibility. it incorporates secure meta transactions via eip-712-enabled signatures and offers optional ens integration for trust verification and discoverability. the interface is equipped to emit specific events for activities like hint modifications, facilitating easy traceability of changes to hints. this setup aims to provide a robust, standardized framework for managing claimand ecosystem-related metadata, essential for maintaining integrity and trustworthiness in decentralized environments. motivation in an increasingly interconnected and decentralized landscape, the formation of trust among entities remains a critical concern. ecosystems, both on-chain and off-chain—spanning across businesses, social initiatives, and other organized frameworks—frequently issue claims for or about entities within their networks. these claims serve as the foundational elements of trust, facilitating interactions and transactions in environments that are essentially untrustworthy by nature. while the decentralization movement has brought about significant improvements around trustless technologies, many ecosystems building on top of these are in need of technologies that build trust in their realm. real-world applications have shown that verifiable claims alone are not enough for this purpose. moreover, a supporting layer of on-chain metadata is needed to support a reliable exchange and verification of those claims. the absence of a structured mechanism to manage claim metadata on-chain poses a significant hurdle to the formation and maintenance of trust among participating entities in an ecosystem. this necessitates the introduction of a layer of on-chain metadata, which can assist in the reliable verification and interpretation of these claims. termed “hints” in this specification, this metadata can be used in numerous ways, each serving to bolster the integrity and reliability of the ecosystem’s claims. hints can perform various tasks, such as providing revocation details, identifying trusted issuers, or offering timestamping hashes. these are just a few examples that enable ecosystems to validate and authenticate claims, as well as verify data integrity over time. the proposed “trusted hint registry” aims to provide a robust, flexible, and standardized interface for managing such hints. the registry allows any address to manage multiple lists of hints, with a set of features that not only make it easier to create and manage these hints but also offer the flexibility of delegating these capabilities to trusted entities. in practice, this turns the hint lists into dynamic tools adaptable to varying requirements and use cases. moreover, an interface has been designed with a keen focus on interoperability, taking into consideration existing w3c specifications around decentralized identifiers and verifiable credentials, as well as aligning with on-chain projects like the ethereum attestation service. by providing a standardized smart contract interface for hint management, this specification plays an integral role in enabling and scaling trust in decentralized ecosystems. it offers a foundational layer upon which claims — both on-chain and off-chain — can be reliably issued, verified, and interpreted, thus serving as an essential building block for the credible operation of any decentralized ecosystem. therefore, the trusted hint registry is not just an addition to the ecosystem but a necessary evolution in the complex topology of decentralized trust. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. this eip specifies a contract called trustedhintregistry and standardizes a set of required core hint functions, while also providing a common set of optional management functions, enabling various ways for collaborative hint management. ecosystems may use this specification to build their own hint registry contracts with ecosystem-specific, non-standardized features. governance is deliberately excluded from this erc and may be implemented according to an ecosystem’s need. definitions claim: a claim is a statement about an entity made by another entity. hint: a “hint” refers to a small piece of information that provides insights, aiding in the interpretation, reliability, or verifiability of decentralized ecosystem data. namespace: a namespace is a representation of an ethereum address inside the registry that corresponds to its owner’s address. a namespace contains hint lists for different use cases. hint list: a hint list is identified by a unique value that contains a number of hint keys that resolve to hint values. an example of this is a revocation key that resolves to a revocation state. hint key: a hint key is a unique value that resolves to a hint value. an example of this is a trusted issuer identifier, which resolves to the trust status of that identifier. hint value: a hint value expresses data about an entity in an ecosystem. delegate: an ethereum address that has been granted writing permissions to a hint list by its owner. interface hint management gethint a method with the following signature must be implemented that returns the hint value in a hint list of a namespace. function gethint(address _namespace, bytes32 _list, bytes32 _key) external view returns (bytes32); sethint a method with the following signature must be implemented that changes the hint value in a hint list of a namespace. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethint(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value) public; sethintsigned a method with the following signature may be implemented that changes the hint value in a hint list of a namespace with a raw signature. the raw signature must be generated following the meta transactions section. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethintsigned(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value, address _signer, bytes calldata _signature) public; sethints a method with the following signature must be implemented that changes multiple hint values in a hint list of a namespace. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethints(address _namespace, bytes32 _list, bytes32[] calldata _keys, bytes32[] calldata _values) public; sethintssigned a method with the following signature must be implemented that multiple hint values in a hint list of a namespace with a raw signature. the raw signature must be generated following the meta transactions section. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethintssigned(address _namespace, bytes32 _list, bytes32[] calldata _keys, bytes32[] calldata _values, address _signer, bytes calldata _signature) public; delegated hint management a namespace owner can add delegate addresses to specific hint lists in their namespace. these delegates shall have write access to the specific lists via a specific set of methods. sethintdelegated a method with the following signature may be implemented that changes the hint value in a hint list of a namespace for pre-approved delegates. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethintdelegated(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value) public; sethintdelegatedsigned a method with the following signature may be implemented that changes the hint value in a hint list of a namespace for pre-approved delegates with a raw signature. the raw signature must be generated following the meta transactions section. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethintdelegatedsigned(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value, address _signer, bytes calldata _signature) public; sethintsdelegated a method with the following signature may be implemented that changes multiple hint values in a hint list of a namespace for pre-approved delegates. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethintsdelegated(address _namespace, bytes32 _list, bytes32[] calldata _keys, bytes32[] calldata _values) public; sethintsdelegatedsigned a method with the following signature may be implemented that has multiple hint values in a hint list of a namespace for pre-approved delegates with a raw signature. the raw signature must be generated following the meta transactions section. an overloaded method with an additional bytes calldata _metadata parameter may be implemented to set metadata together with the hint value. function sethintsdelegatedsigned(address _namespace, bytes32 _list, bytes32[] calldata _keys, bytes32[] calldata _values, address _signer, bytes calldata _signature) public; hint list management setliststatus a method with the following signature may be implemented that changes the validity state of a hint list. this enables one to (un)-revoke a whole list of hint values. function setliststatus(address _namespace, bytes32 _list, bool _revoked) public; setliststatussigned a method with the following signature may be implemented that changes the validity state of a hint list with a raw signature. this enables one to (un)-revoke a whole list of hint values. function setliststatussigned(address _namespace, bytes32 _list, bool _revoked, address _signer, bytes calldata _signature) public; setlistowner a method with the following signature may be implemented that transfers the ownership of a trust list to another address. changing the owner of a list shall not change the namespace the hint list resides in, to retain references of paths to a hint value. function setlistowner(address _namespace, bytes32 _list, address _newowner) public; setlistownersigned a method with the following signature may be implemented that transfers the ownership of a trust list to another address with a raw signature. the raw signature must be generated following the meta transactions section. changing the owner of a list shall not change the namespace the hint list resides in, to retain references to paths to a hint value. function setlistownersigned(address _namespace, bytes32 _list, address _newowner, address _signer, bytes calldata _signature) public; addlistdelegate a method with the following signature may be implemented to add a delegate to an owner’s hint list in a namespace. function addlistdelegate(address _namespace, bytes32 _list, address _delegate, uint256 _untiltimestamp) public; addlistdelegatesigned a method with the following signature may be implemented to add a delegate to an owner’s hint list in a namespace with a raw signature. the raw signature must be generated following the meta transactions section. function addlistdelegatesigned(address _namespace, bytes32 _list, address _delegate, uint256 _untiltimestamp, address _signer, bytes calldata _signature) public; removelistdelegate a method with the following signature may be implemented to remove a delegate from an owner’s revocation hint list in a namespace. function removelistdelegate(address _namespace, bytes32 _list, address _delegate) public; removelistdelegatesigned a method with the following signature may be implemented to remove a delegate from an owner’s revocation hint list in a namespace with a raw signature. the raw signature must be generated following the meta transactions section. function removelistdelegatesigned(address _namespace, bytes32 _list, address _delegate, address _signer, bytes calldata _signature) public; metadata management getmetadata a method with the following signature may be implemented to retrieve metadata for a hint. function getmetadata(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value) external view returns (bytes memory); setmetadata a method with the following signature may be implemented to set metadata for a hint. function setmetadata(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value, bytes calldata _metadata) public; setmetadatasigned a method with the following signature may be implemented to set metadata for a hint with a raw signature. the raw signature must be generated following the meta transactions section. function setmetadatasigned(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value, bytes calldata _metadata, address _signer, bytes calldata _signature) public; setmetadatadelegated a method with the following signature may be implemented to set metadata for a hint as a pre-approved delegate of the hint list. function setmetadatadelegated(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value, bytes calldata _metadata) public; setmetadatadelegatedsigned a method with the following signature may be implemented to set metadata for a hint as a pre-approved delegate of the hint list with a raw signature. the raw signature must be generated following the meta transactions section. function setmetadatadelegatedsigned(address _namespace, bytes32 _list, bytes32 _key, bytes32 _value, bytes calldata _metadata, address _signer, bytes calldata _signature) public; events hintvaluechanged must be emitted when a hint value has changed. event hintvaluechanged( address indexed namespace, bytes32 indexed list, bytes32 indexed key, bytes32 value ); hintlistownerchanged must be emitted when the owner of a list has changed. event hintlistownerchanged( address indexed namespace, bytes32 indexed list, address indexed newowner ); hintlistdelegateadded must be emitted when a delegate has been added to a hint list. event hintlistdelegateadded( address indexed namespace, bytes32 indexed list, address indexed newdelegate ); hintlistdelegateremoved must be emitted when a delegate has been removed from a hint list. event hintlistdelegateremoved( address indexed namespace, bytes32 indexed list, address indexed olddelegate ); hintliststatuschanged must be emitted when the validity status of the hint list has been changed. event hintliststatuschanged( address indexed namespace, bytes32 indexed list, bool indexed revoked ); meta transactions this section uses the following terms: transaction signer: an ethereum address that signs arbitrary data for the contract to execute but does not commit the transaction. transaction sender: an ethereum address that takes signed data from a transaction signer and commits it wrapped in a transaction to the smart contract. a transaction signer may be able to deliver a signed payload off-band to a transaction sender that initiates the ethereum interaction with the smart contract. the signed payload must be limited to being used only once (see signed hash and nonce). signed hash the signature of the transaction signer must conform to eip-712. this helps users understand what the payload they are signing consists of, and it provides protection against replay attacks. nonce this eip recommends the use of a dedicated nonce mapping for meta transactions. if the signature of the transaction sender and its meta-contents are verified, the contract increases a nonce for this transaction signer. this effectively removes the possibility for any other sender to execute the same transaction again with another wallet. trust anchor via ens ecosystems that use an ethereum name service (ens) domain can increase trust by using ens entries to share information about a hint list registry. this method takes advantage of the ens domain’s established credibility to make it easier to find a reliable hint registry contract, as well as the appropriate namespace and hint list customized for particular ecosystem needs. implementing a trust anchor through ens is optional. for each use case, a specific ens subdomain shall be created only used for a specific hint list, e.g., “trusted-issuers.ens.eth”. the following records shall be set: address eth address of the trusted hint registry contract text key: “hint.namespace”; value: owner address of namespace the following records may be set: text key: “hint.list”; value: bytes32 key of hint list text key: “hint.key”; value: bytes32 key of hint key text key: “hint.value”; value: bytes32 key of hint value abi abi of trusted hint registry contract to create a two-way connection, a namespace owner shall set metadata referencing the ens subdomain hash for the hint list. metadata shall be set in the owners namespace, hint list 0x0, and hint key 0x0 where the value is the ens subdomain keccak256 hash. by establishing this connection, a robust foundation for trust and discovery within an ecosystem is created. rationale examining the method signatures reveals a deliberate architecture and data hierarchy within this erc: a namespace address maps to a hint list, which in turn maps to a hint key, which then reveals the hint value. // namespace hint list hint key hint value mapping(address => mapping(bytes32 => mapping(bytes32 => bytes32))) hints; this structure is designed to implicitly establish the initial ownership of all lists under a given namespace, eliminating the need for subsequent claiming actions. as a result, it simplifies the process of verifying and enforcing write permissions, thereby reducing potential attack surfaces. additional data structures must be established and validated for features like delegate management and ownership transfer of hint lists. these structures won’t affect the main namespace layout; rather, they serve as a secondary mechanism for permission checks. one of the primary objectives of this erc is to include management features, as these significantly influence the ease of collaboration and maintainability of hint lists. these features also enable platforms to hide complexities while offering user-friendly interfaces. specifically, the use of meta-transactions allows users to maintain control over their private keys while outsourcing the technical heavy lifting to platforms, which is achieved simply by signing an eip-712 payload. backwards compatibility no backward compatibility issues found. security considerations meta transactions the signature of signed transactions could potentially be replayed on different chains or deployed versions of the registry implementing this erc. this security consideration is addressed by the usage of eip-712. rights management the different roles and their inherent permissions are meant to prevent changes from unauthorized entities. the hint list owner should always be in complete control over its hint list and who has writing access to it. governance it is recognized that ecosystems might have processes in place that might also apply to changes in hint lists. this erc explicitly leaves room for implementers or users of the registry to apply a process that fits the requirements of their ecosystem. possible solutions can be an extension of the contract with governance features around specific methods, the usage of multi-sig wallets, or off-chain processes enforced by an entity. copyright copyright and related rights waived via cc0. citation please cite this document as: philipp bolte (@strumswell), dennis von der bey (@dennisvonderbey), lauritz leifermann (@lleifermann), "erc-7506: trusted hint registry [draft]," ethereum improvement proposals, no. 7506, august 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7506. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7535: native asset erc-4626 tokenized vault ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: erc erc-7535: native asset erc-4626 tokenized vault erc-4626 tokenized vaults with ether (native asset) as the underlying asset authors joey santoro (@joeysantoro) created 2023-10-12 requires eip-20, eip-4626, eip-7528 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification erc-4626 breaking changes methods events wrapped eth rationale allowing assets parameter to be ignored in a deposit allowing msg.value to not equal assets output in a mint backwards compatibility reference implementation security considerations call vs send forceful eth transfers wrapped eth copyright abstract this standard is an extension of the erc-4626 spec with an identical interface and behavioral overrides for handling ether or any native asset as the underlying. motivation a standard for tokenized eth vaults has the same benefits as erc-4626, particularly in the case of liquid staking tokens, (i.e. fungible erc-20 wrappers around eth staking). maintaining the same exact interface as erc-4626 further amplifies the benefits as the standard will be maximally compatible with existing erc-4626 tooling and protocols. specification all erc-7535 tokenized vaults must implement erc-4626 (and by extension erc-20) with behavioral overrides for the methods asset, deposit, and mint specified below. erc-4626 breaking changes any assets quantity refers to wei of ether rather than erc-20 balances. any erc-20 transfer calls are replaced by ether transfer (send or call) any erc-20 transferfrom approval flows for asset are not implemented deposit and mint have state mutability payable deposit uses msg.value as the primary input and may ignore assets methods asset must return 0xeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeeee per erc-7528. name: asset type: function statemutability: view inputs: [] outputs: name: assettokenaddress type: address deposit mints shares vault shares to receiver by depositing exactly msg.value of ether. must have state mutability of payable. must use msg.value as the primary input parameter for calculating the shares output. i.e. may ignore assets parameter as an input. must emit the deposit event. must revert if all of msg.value cannot be deposited (due to deposit limit being reached, slippage, etc). name: deposit type: function statemutability: payable inputs: name: assets type: uint256 name: receiver type: address outputs: name: shares type: uint256 mint mints exactly shares vault shares to receiver by depositing assets of eth. must have state mutability of payable. must emit the deposit event. must revert if all of shares cannot be minted (due to deposit limit being reached, slippage, the user not sending a large enough msg.value of ether to the vault contract, etc). name: mint type: function statemutability: payable inputs: name: shares type: uint256 name: receiver type: address outputs: name: assets type: uint256 events the event usage must be identical to erc-4626. wrapped eth any erc-4626 vault that uses a wrapped eth erc-20 as the asset must not implement erc-7535. erc-7535 only applies to native eth. rationale this standard was designed to maximize compatibility with erc-4626 while minimizing additional opinionated details on the interface. examples of this decision rationale are described below: maintaining the redundant assets input to the deposit function while making its usage optional not enforcing a relationship between msg.value and assets in a mint call not enforcing any behaviors or lack thereof for fallback/__default__ methods, payability on additional vault functions, or handling eth forcibly sent to the contract all breaking implementation level changes with erc-4626 are purely to accomodate for the usage of ether or any native asset instead of an erc-20 token. allowing assets parameter to be ignored in a deposit msg.value must always be passed anyway to fund a deposit, therefore it may as well be treated as the primary input number. allowing assets to be used either forces a strict equality and extra unnecessary gas overhead for redundancy, or allows different values which could cause footguns and undefined behavior. the last option which could work is to require that assets must be 0, but this still requires gas to enforce at the implementation level and can more easily be left unspecified, as the input is functionally ignorable in the spec as written. allowing msg.value to not equal assets output in a mint there may be many cases where a user deposits slightly too much ether in a mint call. in these cases, enforcing msg.value to equal assets would cause unnecessary reversions. it is up to the vault implementer to decide whether to refund or absorb any excess ether, and up to depositors to deposit as close to the exact amount as possible. backwards compatibility erc-7535 is fully backward compatible with erc-4626 at the function interface level. certain implementation behaviors are different due to the fact that eth is not erc-20 compliant, such as the priority of msg.value over assets. it has no known compatibility issues with other standards. reference implementation todo / wip security considerations in addition to all security considerations of erc-4626, there are security implications of having eth as the vault asset. call vs send contracts should take care when using call to transfer eth, as this allows additional reentrancy vulnerabilities and arbitrary code execution beyond what is possible with trusted erc-20 tokens. it is safer to simply send eth with a small gas stipend. implementers should take extra precautions when deciding how to transfer eth. forceful eth transfers eth can be forced into any vault through the selfdestruct opcode. implementers should validate that this does not disrupt vault accounting in any way. similarly, any additional payable methods should be checked to ensure they do not disrupt vault accounting. wrapped eth smart contract systems which implement erc-4626 should consider only supporting erc-20 underlying assets, and default to using a wrapped eth erc-20 instead of implementing erc-7535 for handling eth. the subtle differences between erc-4626 and erc-7535 can introduce code fragmentation and security concerns. cleaner use cases for erc-7535 are eth exclusive, such as wrapped eth and liquid staking tokens. copyright copyright and related rights waived via cc0. citation please cite this document as: joey santoro (@joeysantoro), "erc-7535: native asset erc-4626 tokenized vault [draft]," ethereum improvement proposals, no. 7535, october 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7535. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3030: bls remote signer http api ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3030: bls remote signer http api authors herman junge (@hermanjunge) created 2020-09-30 discussion link https://ethereum-magicians.org/t/eip-3030-bls-remote-signer-http-api-standard/4810 table of contents simple summary abstract motivation specification get /upcheck get /keys post /sign/:identifier rationale unix philosophy: simple api test cases test data get /upcheck get /keys post /sign/:identifier implementation security considerations threat model copyright simple summary this eip defines a http api standard for a bls remote signer, consumed by validator clients to sign block proposals and attestations in the context of ethereum 2.0 (eth2). abstract a validator client contributes to the consensus of the eth2 blockchain by signing proposals and attestations of blocks, using a bls private key which must be available to this client at all times. the bls remote signer api is designed to be consumed by validator clients, looking for a more secure avenue to store their bls12-381 private key(s), enabling them to run in more permissive and scalable environments. motivation eth2 utilizes bls12-381 signatures. consensus on the eth2 blockchain is achieved via the proposal and attestation of blocks from validator clients, using a bls private key (signing key) which must be available each time a message is signed: that is, at least once every epoch (6.4 minutes), during a small window of time within this epoch (a slot, i.e. 12 seconds), as each validator is expected to attest exactly once per epoch. the eth2 specification does not explicitly provide a directive on where this bls private key must/should be stored, leaving this implementation detail to the client teams, who assume that this cryptographic secret is stored on the same host as the validator client. this assumption is sufficient in the use case where the validator client is running in a physically secure network (i.e. nobody, but the operator, has a chance to log-in into the machine hosting the validator client), as such configuration would only allow outbound calls from the validator client. in this situation, only a physical security breach, or a remote code execution (rce) vulnerability can allow an attacker to either have arbitrary access to the storage or to the memory of the device. there are, however, use cases where it is required by the operator to run a validator client node in less constrained security environments, as the ones given by a cloud provider. notwithstanding any security expectation, nothing prevents a rogue operator from gaining arbitrary access to the assets running inside a node. the situation is not better when the requirement is to execute the validators by leveraging a container orchestration solution (e.g. kubernetes). the handling of secret keys across nodes can become a burden both from an operational as well as a security perspective. the proposed solution comprises running a specialized node with exclusive access to the secret keys, listening to a simple api (defined in the specification section), and returning the requested signatures. operators working under this schema must utilize clients with the adequate feature supporting the consumption of this api. the focus of this specification is the supply of bls signatures on demand. the aspects of authentication, key management (creation, update, and deletion), and transport encryption are discussed in the rationale section of this document. moreover, the threat model section of this document provides a (non-exhaustive) list of threats and attack vectors, along with the suggested related mitigation strategy. specification get /upcheck responses success code 200 content {"status": "ok"} get /keys returns the identifiers of the keys available to the signer. responses success code 200 content {"keys": "[identifier]"} post /sign/:identifier url parameter :identifier public_key_hex_string_without_0x request json body bls_domain required the bls signature domain. as defined in the specification, in lowercase, omitting the domain prefix. supporting beacon_proposer, beacon_attester, and randao. data required the data to be signed. as defined in the specifications for block, attestation, and epoch. fork required a fork object containing previous and current versions. as defined in the specification genesis_validators_root required a hash256 for domain separation and chain versioning. optional any other field will be ignored by the signer responses success code 200 content {"signature": ""} where signature is a bls signature byte array encoded as a hexadecimal string. or error code 400 content {"error": ""} or error code 404 content {"error": "key not found: "} rationale unix philosophy: simple api this api specification contains only three methods: one for status, one for listing the available keys, and one to produce a signature. there are no methods for authentication, key management, nor transport encryption. the following subsections discuss aspects to be considered by the client implementers relative to these subjects. implementation of additional features from an api pipeline view, we have two nodes: the validator client (1) that makes requests to the remote signer (2). a more sophisticated chain can be built by introducing elements between these two nodes. either by setting up reverse proxy services, or by adding plugins to the remote signer implementation. authentication can be accomplished through the use of an http request header. there are several ways to negotiate and issue a valid token to authenticate the communication between the validator client and the remote signer, each of them with potential drawbacks (e.g replay attacks, challenges in distributing the token to the validator client, etc.). in general, any method of authentication must be combined with transport encryption to be effective. the operator can also implement network access control lists (acls) between the validator client’s network and the remote signer’s network, reducing the attack surface by requiring a potential attacker to be positioned in the same network as the validator client. key management there are several ways to store secret keys, namely hardware security modules (hsm), secrets management applications (e.g. hashicorp vault), cloud storage with tight private network acl rules, or even raw files in a directory. in general the remote signer implementers will abstract the storage medium from the http api. it is in this perspective, that any procedure to create, update, or delete keys should be built separate from the client implementation. transport encryption if the operator is working with self-signed certificates, it is required that the client enhancement consuming the remote signer allows this option. test cases test data bls pair public key: 0xb7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a. secret key: 0x68081afeb7ad3e8d469f87010804c3e8d53ef77d393059a55132637206cc59ec. signing root: 0xb6bb8f3765f93f4f1e7c7348479289c9261399a3c6906685e320071a1a13955c. expected signature: 0xb5d0c01cef3b028e2c5f357c2d4b886f8e374d09dd660cd7dd14680d4f956778808b4d3b2ab743e890fc1a77ae62c3c90d613561b23c6adaeb5b0e288832304fddc08c7415080be73e556e8862a1b4d0f6aa8084e34a901544d5bb6aeed3a612. get /upcheck # success ## request curl -v localhost:9000/upcheck ## response * trying 127.0.0.1:9000... * tcp_nodelay set * connected to localhost (127.0.0.1) port 9000 (#0) > get /upcheck http/1.1 > host: localhost:9000 > user-agent: curl/7.68.0 > accept: */* > * mark bundle as not supporting multiuse < http/1.1 200 ok < content-type: application/json < content-length: 15 < date: wed, 30 sep 2020 02:25:08 gmt < * connection #0 to host localhost left intact {"status":"ok"} get /keys # success ## request curl -v localhost:9000/keys ## response * trying 127.0.0.1:9000... * tcp_nodelay set * connected to localhost (127.0.0.1) port 9000 (#0) > get /publickeys http/1.1 > host: localhost:9000 > user-agent: curl/7.68.0 > accept: */* > * mark bundle as not supporting multiuse < http/1.1 200 ok < content-type: application/json < content-length: 116 < date: wed, 30 sep 2020 02:25:36 gmt < * connection #0 to host localhost left intact {"keys":["b7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a"]} # server error ## preparation ## `chmod` keys directory to the octal 311 (-wx--x--x). ## request curl -v localhost:9000/keys ## response * trying 127.0.0.1:9000... * tcp_nodelay set * connected to localhost (127.0.0.1) port 9000 (#0) > get /publickeys http/1.1 > host: localhost:9000 > user-agent: curl/7.68.0 > accept: */* > * mark bundle as not supporting multiuse < http/1.1 500 internal server error < content-length: 43 < date: wed, 30 sep 2020 02:26:09 gmt < * connection #0 to host localhost left intact {"error":"storage error: permissiondenied"} post /sign/:identifier # success ## request curl -v -x post -d @payload.json -h 'content-type: application/json' localhost:9000/sign/b7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a ## response note: unnecessary use of -x or --request, post is already inferred. * trying 127.0.0.1:9000... * tcp_nodelay set * connected to localhost (127.0.0.1) port 9000 (#0) > post /sign/b7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a http/1.1 > host: localhost:9000 > user-agent: curl/7.68.0 > accept: */* > content-type: application/json > content-length: 84 > * upload completely sent off: 84 out of 84 bytes * mark bundle as not supporting multiuse < http/1.1 200 ok < content-type: application/json < content-length: 210 < date: wed, 30 sep 2020 02:16:02 gmt < * connection #0 to host localhost left intact {"signature":"0xb5d0c01cef3b028e2c5f357c2d4b886f8e374d09dd660cd7dd14680d4f956778808b4d3b2ab743e890fc1a77ae62c3c90d613561b23c6adaeb5b0e288832304fddc08c7415080be73e556e8862a1b4d0f6aa8084e34a901544d5bb6aeed3a612"} # bad request error ## request curl -v -x post -d 'foobar' -h 'content-type: application/json' localhost:9000/sign/b7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a ## response note: unnecessary use of -x or --request, post is already inferred. * trying 127.0.0.1:9000... * tcp_nodelay set * connected to localhost (127.0.0.1) port 9000 (#0) > post /sign/b7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a http/1.1 > host: localhost:9000 > user-agent: curl/7.68.0 > accept: */* > content-type: application/json > content-length: 23 > * upload completely sent off: 23 out of 23 bytes * mark bundle as not supporting multiuse < http/1.1 400 bad request < content-length: 38 < date: wed, 30 sep 2020 02:15:05 gmt < * connection #0 to host localhost left intact {"error":"unable to parse body message from json: error(\"expected ident\", line: 1, column: 2)"} # no keys available ## request curl -v -x post -d @payload.json -h 'content-type: application/json' localhost:9000/sign/000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 ## response note: unnecessary use of -x or --request, post is already inferred. * trying 127.0.0.1:9000... * tcp_nodelay set * connected to localhost (127.0.0.1) port 9000 (#0) > post /sign/000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 http/1.1 > host: localhost:9000 > user-agent: curl/7.68.0 > accept: */* > content-type: application/json > content-length: 84 > * upload completely sent off: 84 out of 84 bytes * mark bundle as not supporting multiuse < http/1.1 404 not found < content-length: 123 < date: wed, 30 sep 2020 02:18:53 gmt < * connection #0 to host localhost left intact {"error":"key not found: 000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000"} # server error ## preparation ## `chmod` both keys directory and file to the octal 311 (-wx--x--x). ## `chmod` back to 755 to delete them afterwards. ## request curl -v -x post -d @payload.json -h 'content-type: application/json' localhost:9000/sign/b7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a ## response note: unnecessary use of -x or --request, post is already inferred. * trying 127.0.0.1:9000... * tcp_nodelay set * connected to localhost (127.0.0.1) port 9000 (#0) > post /sign/b7354252aa5bce27ab9537fd0158515935f3c3861419e1b4b6c8219b5dbd15fcf907bddf275442f3e32f904f79807a2a http/1.1 > host: localhost:9000 > user-agent: curl/7.68.0 > accept: */* > content-type: application/json > content-length: 84 > * upload completely sent off: 84 out of 84 bytes * mark bundle as not supporting multiuse < http/1.1 500 internal server error < content-length: 43 < date: wed, 30 sep 2020 02:21:08 gmt < * connection #0 to host localhost left intact {"error":"storage error: permissiondenied"} implementation repository url language organization commentary bls remote signer rust sigma prime supports proposed specification. web3signer java pegasys supports proposed specification, although with slightly different methods: {/sign => /api/v1/eth2/sign, /publickeys => /api/v1/eth2/publickeys}. remote signing wallet golang prysmatics labs supports both grpc and json over http. security considerations threat model let’s consider the following threats and their mitigations: threat mitigation(s) an attacker can spoof the validator client. see the discussion at authentication. an attacker can send a crafted message to the signer, leading to a slashing offense. it is the responsibility of the operator of the remote signer to add a validation module, as discussed at implementation of additional features. an attacker can create, update, or delete secret keys. keys are not to be writable via any interface of the remote signer. an attacker can repudiate a sent message. implement logging in the signer. enhance it by sending logs to a syslog box. an attacker can disclose the contents of a private key by retrieving the key from storage. storage in hardware security module (hsm). or storage in secrets management applications (e.g. hashicorp vault). an attacker can eavesdrop on the uploading of a secret key. upload the keys using a secure channel, based on each storage specification. an attacker can eavesdrop on the retrieval of a key from the remote signer. always pass the data between storage and remote signer node using a secure channel. an attacker can dump the memory in the remote signer to disclose a secret key. prevent physical access to the node running the remote signer. or prevent access to the terminal of the node running the remote signer: logs being sent to a syslog box. deployments triggered by a simple, non-parameterized api. or implement zeroization of the secret key at memory. or explore the compilation and running of the remote signer in a trusted execution environment (tee). an attacker can dos the remote signer. implement ip filtering. or implement rate limiting. copyright copyright and related rights waived via cc0. citation please cite this document as: herman junge (@hermanjunge), "eip-3030: bls remote signer http api [draft]," ethereum improvement proposals, no. 3030, september 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3030. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7007: zero-knowledge ai-generated content token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7007: zero-knowledge ai-generated content token an erc-721 extension interface for zkml based aigc-nfts. authors cathie so (@socathie), xiaohang yu (@xhyumiracle), huaizhe xu (@huaizhexu), kartin created 2023-05-10 discussion link https://ethereum-magicians.org/t/eip-7007-zkml-aigc-nfts-an-erc-721-extension-interface-for-zkml-based-aigc-nfts/14216 requires eip-165, eip-721 table of contents abstract motivation specification rationale backwards compatibility test cases reference implementation security considerations copyright abstract the zero-knowledge machine lerning (zkml) ai-generated content (aigc) non-fungible token (nft) standard is an extension of the erc-721 token standard for aigc. it proposes a set of interfaces for basic interactions and enumerable interactions for aigc-nfts. the standard includes a new mint event and a json schema for aigc-nft metadata. additionally, it incorporates zkml capabilities to enable verification of aigc-nft ownership. in this standard, the tokenid is indexed by the prompt. motivation the zkml aigc-nfts standard aims to extend the existing erc-721 token standard to accommodate the unique requirements of ai-generated content nfts representing models in a collection. this standard provides interfaces to use zkml to verify whether or not the aigc data for an nft is generated from a certain ml model with certain input (prompt). the proposed interfaces allow for additional functionality related to minting, verifying, and enumerating aigc-nfts. additionally, the metadata schema provides a structured format for storing information related to aigc-nfts, such as the prompt used to generate the content and the proof of ownership. with this standard, model owners can publish their trained model and its zkp verifier to ethereum. any user can claim an input (prompt) and publish the inference task, any node that maintains the model and the proving circuit can perform the inference and proving, then submit the output of inference and the zk proof for the inference trace into the verifier that is deployed by the model owner. the user that initiates the inference task will own the output for the inference of that model and input (prompt). specification the keywords “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. every compliant contract must implement the erc-7007, erc-721, and erc-165 interfaces. the zkml aigc-nfts standard includes the following interfaces: ierc7007: defines a mint event and a mint function for minting aigc-nfts. it also includes a verify function to check the validity of a combination of prompt and proof using zkml techniques. pragma solidity ^0.8.18; /** * @dev required interface of an erc7007 compliant contract. * note: the erc-165 identifier for this interface is 0x7e52e423. */ interface ierc7007 is ierc165, ierc721 { /** * @dev emitted when `tokenid` token is minted. */ event mint( uint256 indexed tokenid, bytes indexed prompt, bytes indexed aigcdata, string uri, bytes proof ); /** * @dev mint token at `tokenid` given `prompt`, `aigcdata`, `uri` and `proof`. * * requirements: * `tokenid` must not exist.' * verify(`prompt`, `aigcdata`, `proof`) must return true. * * optional: * `proof` should not include `aigcdata` to save gas. */ function mint( bytes calldata prompt, bytes calldata aigcdata, string calldata uri, bytes calldata proof ) external returns (uint256 tokenid); /** * @dev verify the `prompt`, `aigcdata` and `proof`. */ function verify( bytes calldata prompt, bytes calldata aigcdata, bytes calldata proof ) external view returns (bool success); } optional extension: enumerable the enumeration extension is optional for erc-7007 smart contracts. this allows your contract to publish its full list of mapping between tokenid and prompt and make them discoverable. pragma solidity ^0.8.18; /** * @title erc7007 token standard, optional enumeration extension * note: the erc-165 identifier for this interface is 0xfa1a557a. */ interface ierc7007enumerable is ierc7007 { /** * @dev returns the token id given `prompt`. */ function tokenid(bytes calldata prompt) external view returns (uint256); /** * @dev returns the prompt given `tokenid`. */ function prompt(uint256 tokenid) external view returns (string calldata); } erc-7007 metadata json schema for reference { "title": "aigc metadata", "type": "object", "properties": { "name": { "type": "string", "description": "identifies the asset to which this nft represents" }, "description": { "type": "string", "description": "describes the asset to which this nft represents" }, "image": { "type": "string", "description": "a uri pointing to a resource with mime type image/* representing the asset to which this nft represents. consider making any images at a width between 320 and 1080 pixels and aspect ratio between 1.91:1 and 4:5 inclusive." }, "prompt": { "type": "string", "description": "identifies the prompt from which this aigc nft generated" }, "aigc_type": { "type": "string", "description": "image/video/audio..." }, "aigc_data": { "type": "string", "description": "a uri pointing to a resource with mime type image/* representing the asset to which this aigc nft represents." } } } rationale tbd backwards compatibility this standard is backward compatible with the erc-721 as it extends the existing functionality with new interfaces. test cases the reference implementation includes sample implementations of the erc-7007 interfaces under contracts/ and corresponding unit tests under test/. this repo can be used to test the functionality of the proposed interfaces and metadata schema. reference implementation erc-7007 erc-7007 enumerable extension security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: cathie so (@socathie), xiaohang yu (@xhyumiracle), huaizhe xu (@huaizhexu), kartin , "erc-7007: zero-knowledge ai-generated content token [draft]," ethereum improvement proposals, no. 7007, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7007. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-607: hardfork meta: spurious dragon ethereum improvement proposals allcorenetworkinginterfaceercmetainformational meta eip-607: hardfork meta: spurious dragon authors alex beregszaszi (@axic) created 2017-04-23 requires eip-155, eip-160, eip-161, eip-170, eip-608 table of contents abstract specification references copyright abstract this specifies the changes included in the hard fork named spurious dragon. specification codename: spurious dragon aliases: state-clearing activation: block >= 2,675,000 on mainnet block >= 1,885,000 on morden included eips: eip-155 (simple replay attack protection) eip-160 (exp cost increase) eip-161 (state trie clearing) eip-170 (contract code size limit) references https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/ copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), "eip-607: hardfork meta: spurious dragon," ethereum improvement proposals, no. 607, april 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-607. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1011: hybrid casper ffg ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1011: hybrid casper ffg authors danny ryan (@djrtwo), chih-cheng liang (@chihchengliang) created 2018-04-20 discussion link https://github.com/djrtwo/eips/issues/5 table of contents simple summary abstract glossary motivation parameters casper contract parameters specification rationale backwards compatibility copyright simple summary specification of the first step to transition ethereum main net from proof of work (pow) to proof of stake (pos). the resulting consensus model is a pow/pos hybrid. abstract this eip specifies a hybrid pow/pos consensus model for ethereum main net. existing pow mechanics are used for new block creation, and a novel pos mechanism called casper the friendly finality gadget (ffg) is layered on top using a smart contract. through the use of ether deposits, slashing conditions, and a modified fork choice, ffg allows the underlying pow blockchain to be finalized. as network security is greatly shifted from pow to pos, pow block rewards are reduced. this eip does not contain safety and liveness proofs or validator implementation details, but these can be found in the casper ffg paper and validator implementation guide respectively. glossary epoch: the span of blocks between checkpoints. epochs are numbered starting at the hybrid casper fork, incrementing by one at the start of each epoch. finality: the point at which a block has been decided upon by a client to never revert. proof of work does not have the concept of finality, only of further deep block confirmations. checkpoint: the block/hash under consideration for finality for a given epoch. this block is the last block of the previous epoch. rather than dealing with every block, casper ffg only considers checkpoints for finalization. when a checkpoint is explicitly finalized, all ancestor blocks of the checkpoint are implicitly finalized. validator: a participant in the casper ffg consensus that has deposited ether in the casper contract and has the responsibility to vote and finalize checkpoints. validator set: the set of validators in the casper contract at any given time. dynasty: the number of finalized checkpoints in the chain from root to the parent of a block. the dynasty is used to define when a validator starts and ends validating. the current dynasty only increments when a checkpoint is finalized as opposed to epoch numbers that increment regardless of finality. slash: the burning of some amount of a validator’s deposit along with an immediate logout from the validator set. slashing occurs when a validator signs two conflicting vote messages that violate a slashing condition. for an in-depth discussion of slashing conditions, see the casper ffg paper. motivation transitioning the ethereum network from pow to pos has been on the roadmap and in the yellow paper since the launch of the protocol. although effective in coming to a decentralized consensus, pow consumes an incredible amount of energy, has no economic finality, and has no effective strategy in resisting cartels. excessive energy consumption, issues with equal access to mining hardware, mining pool centralization, and an emerging market of asics each provide a distinct motivation to make the transition as soon as possible. until recently, the proper way to make this transition was still an open area of research. in october of 2017 casper the friendly finality gadget was published, solving open questions of economic finality through validator deposits and crypto-economic incentives. for a detailed discussion and proofs of “accountable safety” and “plausible liveness”, see the casper ffg paper. the casper ffg contract can be layered on top of any block proposal mechanism, providing finality to the underlying chain. this eip proposes layering ffg on top of the existing pow block proposal mechanism as a conservative step-wise approach in the transition to full pos. the new ffg staking mechanism requires minimal changes to the protocol, allowing the ethereum network to fully test and evaluate casper ffg on top of pow before moving to a validator based block proposal mechanism. parameters hybrid_casper_fork_blknum: tbd casper_addr: tbd casper_code: see below casper_balance: 1.25e24 wei (1,250,000 eth) msg_hasher_addr: tbd msg_hasher_code: see below purity_checker_addr: tbd purity_checker_code: see below null_sender: 2**160 1 new_block_reward: 6e17 wei (0.6 eth) reward_stepdown_block_count: 5.5e5 blocks (~3 months) casper_init_data: tbd vote_bytes: 0xe9dc0614 initialize_epoch_bytes: 0x5dcffc17 non_revert_min_deposit: amount in wei configurable by client casper contract parameters epoch_length: 50 blocks warm_up_period: 1.8e5 blocks (~1 month) withdrawal_delay: 1.5e4 epochs dynasty_logout_delay: 700 dynasties base_interest_factor: 7e-3 base_penalty_factor: 2e-7 min_deposit_size: 1.5e21 wei (1500 eth) specification deploying casper contract if block.number == hybrid_casper_fork_blknum, then when processing the block before processing any transactions: set the code of msg_hasher_addr to msg_hasher_code set the code of purity_checker_addr to purity_checker_code set the code of casper_addr to casper_code set balance of casper_addr to casper_balance then execute a call with the following parameters before executing any normal block transactions: sender: null_sender gas: 3141592 to: casper_addr value: 0 nonce: 0 gasprice: 0 data: casper_init_data this call utilizes no gas and does not increment the nonce of null_sender initialize epochs if block.number >= (hybrid_casper_fork_blknum + warm_up_period) and block.number % epoch_length == 0, execute a call with the following parameters before executing any normal block transactions: sender: null_sender gas: 3141592 to: casper_addr value: 0 nonce: 0 gasprice: 0 data: initialize_epoch_bytes followed by the 32-byte encoding of floor(block.number / epoch_length) this call utilizes no gas and does not increment the nonce of null_sender casper votes a vote transaction is defined as a transaction with the following parameters: to: casper_addr data: begins with vote_bytes if block.number >= hybrid_casper_fork_blknum, then: a valid vote transaction to casper_addr must satisfy each of the following: must have the following signature (chain_id, 0, 0) (ie. r = s = 0, v = chain_id) must have value == nonce == gasprice == 0 when producing and validating a block, when handling vote transactions to casper_addr: only include “valid” vote transactions as defined above place all vote transactions at the end of the block track cumulative gas used by votes separately from cumulative gas used by normal transactions via vote_gas_used total vote_gas_used of vote transactions cannot exceed the block_gas_limit, independent of gas used by normal block transactions when applying vote transactions to casper_addr to vm state: set sender to null_sender count gas of vote toward vote_gas_used do not count gas of vote toward the normal gas_used. for all vote transaction receipts, cumulative gas used is equal to last non-vote transaction receipt do not increment the nonce of null_sender all unsuccessful vote transactions to casper_addr are invalid and must not be included in the block fork choice and finalization if block.number >= hybrid_casper_fork_blknum, the fork choice rule is the logic represented by the following pseudocode. note that options --casper-fork-choice and --exclude are discussed below in “client settings”. def handle_block(new_block): if not is_new_head(new_block): return set_head(new_block) if --casper-fork-choice is on: check_and_finalize_new_checkpoint(new_block) def is_new_head(new_block): if --casper-fork-choice is off # old pure pow chain scoring rule return new_block.total_difficuty > current_head.total_difficulty if new_block is in --exclude list or one of its descendants return false # don't revert finalized blocks if db.last_finalized_block is not in new_block.ancestors: return false # new casper chain scoring rule return highest_justified_epoch(new_block) * 10**40 + new_block.total_difficuty > highest_justified_epoch(current_head) * 10**40 + current_head.total_difficulty def highest_justified_epoch(block): casper = block.post_state.casper_contract return casper.highest_justified_epoch(non_revert_min_deposits) def check_and_finalize_new_checkpoint(new_block): casper = new_block.post_state.casper_contract # if no finalized blocks, db.last_finalized_epoch initialized to -1 finalized_epoch = casper.highest_finalized_epoch(non_revert_min_deposits) if finalized_epoch > db.last_finalized_epoch: finalized_hash = casper.checkpoint_hashes(finalized_epoch) # ensure not trivially finalized if finalized_hash == b'\x00' * 32: return db.last_finalized_epoch = finalized_epoch db.last_finalized_block = finalized_hash the new chain scoring rule queries the casper contract to find the highest justified epoch that meets the client’s minimum deposit requirement (non_revert_min_deposits). the 10**40 multiplier ensures that the justified epoch takes precedence over block mining difficulty. total_difficulty only serves as a tie breaker if the two blocks in question have an equivalent highest_justified_epoch. note: if the client has no justified checkpoints, the contract returns highest_justified_epoch as 0 essentially reverting the fork choice rule to pure pow. when assessing a new block as the chain’s head, clients must never revert finalized blocks as seen by the code commented as “don’t revert finalized blocks”. when a new block is added as the chain’s head, clients then check for a new finalized block. this is handled by the check_and_finalized_new_checkpoint(new_block) method above. if the highest finalized epoch in the casper contract is greater than the previous finalized epoch, then the client finalizes the block with the hash casper.checkpoint_hashes(finalized_epoch), storing this block and the related epoch number in the client database as finalized. clients only consider checkpoints justified or finalized if deposits were greater than non_revert_min_deposit during the epoch in question. this logic is encapsulated in casper.highest_justified_epoch(non_revert_min_deposit) and casper.highest_finalized_epoch(non_revert_min_deposit), respectively. block reward if block.number >= hybrid_casper_fork_blknum, then block_reward is defined by the following logic and utilizes the same formulas for ommer rewards but with the updated block_reward. if block.number < hybrid_casper_fork_blknum + reward_stepdown_block_count: block_reward = 5 * new_block_reward elif block.number < hybrid_casper_fork_blknum + 2*reward_stepdown_block_count: block_reward = 4 * new_block_reward elif block.number < hybrid_casper_fork_blknum + 3*reward_stepdown_block_count: block_reward = 3 * new_block_reward elif block.number < hybrid_casper_fork_blknum + 4*reward_stepdown_block_count: block_reward = 2 * new_block_reward else: block_reward = new_block_reward validators the mechanics and responsibilities of validators are not specified in this eip because they rely upon network transactions to the contract at casper_addr rather than on protocol level implementation and changes. see the validator implementation guide for validator details. msg_hasher_code the source code for msg_hasher_code is located here. the source is to be migrated to vyper lll before the bytecode is finalized for this eip. the evm init code is: tbd the evm bytecode that the contract should be set to is: tbd purity_checker_code the source code for purity_checker_code is located here. the source is to be migrated to vyper lll before the bytecode is finalized for this eip. the evm init code is: tbd the evm bytecode that the contract should be set to is: tbd casper_code the source code for casper_code is located at here. the contract is to be formally verified and further tested before the bytecode is finalized for this eip. the evm init code with the above specified params is: tbd the evm bytecode that the contract should be set to is: tbd client settings clients should be implemented with the following configurable settings: enable casper fork choice the ability to enable/disable the casper fork choice. a suggested implementation is --casper-fork-choice. this setting should ship as default disabled in client versions during the initial casper fork. this setting should ship as default enabled in subsequent client versions. non_revert_min_deposit the minimum size of total deposits that the client must observe in the ffg contract for the state of the contract to affect the client’s fork choice. a suggested implementation is --non-revert-min-deposit wei_value. the suggested default value that clients should ship with is at least 2e23 wei (200k eth). see “fork choice” more details. exclusion the ability to exclude a specified blockhash and all of its descendants from a client’s fork choice. a suggested implementation is --exclude blockhashes, where block_hashes is a comma delimited list of blockhashes to exclude. note: this can by design override a client’s forkchoice and revert finalized blocks. join fork the ability to manually join a fork specified by a blockhash. a suggested implementation is --join-fork blockhash where the client automatically sets the head to the block defined byblockhash and locally finalizes it. note: this can by design override a client’s forkchoice and revert finalized blocks. monitor votes the ability to monitor incoming vote transactions for slashing conditions and submit proof to the casper contract for a finder’s fee if found. a suggested implementation is --monitor-votes. the setting should default to disabled. the following pseudocode defines when two vote messages violate a slashing condition. a vote message is the singular argument included in a vote transaction. def decode_rlp_list(vote_msg): # [validator_index, target_hash, target_epoch, source_epoch, signature] return rlplist(vote_msg, [int, bytes, int, int, bytes]) def same_target_epoch(vote_msg_1, vote_msg_2): decoded_values_1 = decode_rlp_msg(vote_msg_1) target_epoch_1 = decoded_values_1[2] decoded_values_2 = decode_rlp_msg(vote_msg_2) target_epoch_2 = decoded_values_2[2] return target_epoch_1 == target_epoch_2 def surrounds(vote_msg_1, vote_msg_2): decoded_values_1 = decode_rlp_msg(vote_msg_1) target_epoch_1 = decoded_values_1[2] source_epoch_1 = decoded_values_1[3] decoded_values_2 = decode_rlp_msg(vote_msg_2) target_epoch_2 = decoded_values_2[2] source_epoch_1 = decoded_values_1[3] vote_1_surrounds_vote_2 = target_epoch_1 > target_epoch_2 and source_epoch_1 < source_epoch_2 vote_2_surrounds_vote_1 = target_epoch_2 > target_epoch_1 and source_epoch_2 < source_epoch_1 return vote_1_surrounds_vote_2 or vote_2_surrounds_vote_1 def violates_slashing_condition(vote_msg_1, vote_msg_2): return same_target_epoch(vote_msg_1, vote_msg_2) or surrounds(vote_msg_1, vote_msg_2) the casper contract also provides a helper method slashable(vote_msg_1, vote_msg_2) to check if two votes violate a slashing condition. clients should use the above pseudocode in combination with casper.slashable() as a final check when deciding whether to submit a slash to the contract. the --monitor-votes setting is to be used for clients that wish to monitor vote transactions for slashing conditions. if a slashing condition is found, the client creates and sends a transaction to slash on the casper contract. the first transaction to include the slashing condition proof slashes the validator in question and sends a 4% finder’s fee to the transaction sender. rationale naive pos specifications and implementations have existed since early blockchain days, but most are vulnerable to serious attacks and do not hold up under crypto-economic analysis. casper ffg solves problems such as “nothing at stake” and “long range attacks” through requiring validators to post slashable deposits and through defining economic finality. minimize consensus changes the finality gadget is designed to minimize changes across clients. for this reason, ffg is implemented within the evm, so that the contract byte code encapsulates most of the complexity of the fork. most other decisions were made to minimize changes across clients. for example, it would be possible to allow casper_addr to mint ether each time it paid rewards (as compared to creating the contract with casper_balance), but this would be more invasive and error-prone than relying on existing evm mechanics. deploying casper contract the msg_hasher_code and purity_checker_code both do not require any initialization so the evm bytecode can simply be placed at msg_hasher_addr and purity_checker_addr. on the other hand, the casper contract does require passing in parameters and initialization of state. this initialization would normally occur by the evm init code interacting with the create opcode. due to the nature of this contract being deployed outside of normal block transactions and to a particular address, the evm init code/create method requires client specific “hacks” to make it work. for simplicity of specifying across clients, the evm bytecode – casper_code – is placed at casper_addr followed by an explicit call to a one-time init method on the casper contract. init handles all of the logic that a constructor normally would, accepting contract parameters as arguments and setting initial variable values, and can only be run once. casper_init_data is composed of the the byte signature of the init method of the casper contract concatenated with the 32-byte encodings of the following variables in the following order: epoch_length withdrawal_delay dynasty_logout_delay msg_hasher_addr purity_checker_addr base_interest_factor base_penalty_factor min_deposit_size the entirety of this data is provided as a bytestring – casper_init_data – to reduce the chance of encoding errors across clients, especially regarding fixed decimal types which are new in vyper and not yet supported by all clients. casper contract params epoch_length is set to 50 blocks as a balance between time to finality and message overhead. warm_up_period is set to 1.8e5 blocks to provide validators with an approximate 1 month period to make initial deposits before full contract functionality and voting begin. this helps prevent degenerate cases such as having very few or even just one validator in the initial dynasty. this 1 month period also gives the network time to observe on the order of how many validators will initially be participating in consensus. if for some reason there is an unexpectedly low turnout, the community might choose to delay validation and consider design alternatives. withdrawal_delay is set to 15000 epochs to freeze a validator’s funds for approximately 4 months after logout. this allows for at least a 4 month window to identify and slash a validator for attempting to finalize two conflicting checkpoints. this also defines the window of time with which a client must log on to sync the network due to weak subjectivity. dynasty_logout_delay is set to 700 dynasties to prevent immediate logout in the event of an attack from being a viable strategy. base_interest_factor is set to 7e-3 such that if there are ~10m eth in total deposits, then validators earn approximately 5% per year in eth rewards under optimal ffg conditions. base_penalty_factor is set to 2e-7 such that if 50% of deposits go offline, then offline validators lose half of their deposits in approximately 3 weeks, at which the online portion of validators becomes a 2/3 majority and can begin finalizing checkpoints again. min_deposit_size is set to 1500 eth to form a natural upper bound on the total number of validators, bounding the overhead due to vote messages. using formulas found here under “from validator count to minimum staking eth”, we estimate that with 1500 eth minimum deposit at an assumed ~10m in total deposits there will be approximately 900 validators at any given time. votes are only sent after the first quarter of an epoch so 900 votes have to fit into 37 blocks or ~24 votes per block. we have experimented with more dynamic models for min_deposit_size, but these tend to introduce significant complexities and without data from a live network seem to be premature optimizations. initialize epochs the call to the method at initialize_epoch_bytes at casper_addr at the start of each epoch is a call to the initialize_epoch method in the casper contract. this method can only be called once per epoch and is guaranteed by the protocol to be called at the start block of each epoch by null_sender. this method performs a number of bookkeeping tasks around incrementing variables, updating rewards, etc. any call to this method fails prior to the end of the warm_up_period. thus the protocol does not begin executing initialize_epoch calls until block.number >= hybrid_casper_fork_blknum + warm_up_period. issuance a fixed amount of 1.25m eth was chosen as casper_balance to fund the casper contract. this gives the contract enough runway to operate for approximately 2 years (assuming ~10m eth in validator deposits). acting similarly to the “difficulty bomb”, this “funding crunch” forces the network to hardfork in the relative near future to further fund the contract. this future hardfork is an opportunity to upgrade the contract and transition to full pos. the pow block reward is reduced from 3.0 to 0.6 eth/block over the course of approximately one year because the security of the chain is greatly shifted from pow difficulty to pos finality and because rewards are now issued to both validators and miners. rewards are stepped down by 0.6 eth/block every 3 months (reward_stepdown_block_count) to provide for a conservative transition period from full pow to hybrid pos/pow. this gives validators time to become familiar with the new technology and begin logging on and also provides the network with more leeway in case of any unforeseen issues. if any major issues do arise, the ethereum network will still have substantial pow security to rely upon while decisions are made and/or patches are deployed. see here for further analysis of the current pow security and of the effect of pow block reward reduction in the context of hybrid casper ffg. in addition to block rewards, miners now receive an issuance reward for including successful vote transactions into the block on time. this reward is equal to 1/8th that of the reward the validator receives for a successful vote transaction. under optimal ffg conditions after group validator reward adjustments are made, miners receive approximately 1/5th of the total eth issued by the casper contract. below is a table of deposit sizes with associated annual interest rate and approximate time until funding crunch: deposit size annual validator interest funding crunch 2.5m eth 10.12% ~4 years 10m eth 5.00% ~2 years 20m eth 3.52% ~1.4 years 40m eth 2.48% ~1 year gas changes normal block transactions cannot affect casper vote validation results, but casper vote validation results can affect normal block transaction execution. due to this asymmetrical relationship, vote transactions can be processed in parallel with normal block transactions if vote transactions are placed after all normal block transactions. because vote transactions can be processed in parallel to normal block transactions, vote transactions cost 0 gas for validators, ensuring that validators can submit votes even in highly congested or high gas-price periods. vote_gas_used is introduced to ensure that vote transactions do not put an undue burden on block processing. the additional overhead from vote transactions is capped at the same limit as normal block transactions so that, when run in parallel, neither sets of transactions exceed the overhead defined by the block_gas_limit. the call to initialize_epoch at the beginning of each epoch requires 0 gas so that this protocol state transition does not take any gas allowance away from normal transactions. null_sender and account abstraction this eip implements a limited version of account abstraction for validators’ vote transactions. the general design was borrowed from eip-86. rather than relying upon native transaction signatures, each validator specifies a signature contract when sending their deposit to casper_addr. when casting a vote, the validator bundles and signs the parameters of their vote according to the requirements of their signature contract. the vote method of the casper contract checks the signature of the parameters against the validator’s signature contract, exiting the transaction as unsuccessful if the signature is not successfully verified. this allows validators to customize their own signing scheme for votes. use cases include: quantum-secure signature schemes multisig wallets threshold schemes for more details on validator account abstraction, see the validator implementation guide. client settings enable casper fork choice releasing client versions with the casper fork choice as initially default disabled allows for a more conservative transition to hybrid casper ffg. under normal operating conditions there are no disparities between the pow fork choice and the hybrid casper ffg fork choice. the two fork choice rules can only diverge if either 51% of miners or 51% of validators are faulty. validators will begin to log on, vote, and finalize the ffg contract before the majority of the network begins explicitly relying upon the new finality mechanism. once a significant number of validators have logged on and the finality mechanism has been tested on the live network, new client software versions that change the default to enabled will be released. non_revert_min_deposit non_revert_min_deposit is defined and configurable locally by each client. clients are in charge of deciding upon the minimum deposits (security) at which they will accept the chain as finalized. in the general case, differing values in the choice of this local constant will not create any fork inconsistencies because clients with very strict finalization requirements will revert to follow the longest pow chain. arguments have been made to hardcode a value into clients or the contract, but we cannot reasonably define security required for all clients especially in the context of massive fluctuations in the value of eth. exclusion this setting is useful in coordinating minority forks in cases of majority collusion. join fork this setting is to be used by new clients that are syncing the network for the first time. due to weak subjectivity, a blockhash should be supplied to successfully sync the network when initially starting a node. this setting is also useful for coordinating minority forks in cases of majority collusion. monitor votes monitoring the network for slashing conditions is key to casper ffg’s “accountable safety” as submitting proof of nefarious activity burns a validator’s deposit. this setting is suggested default disabled because the block producer will almost certainly frontrun anyone else submitting a slash transaction. to prevent every client on the network from submitting a slash transaction in the event of a slashing condition, this setting should only be enabled by block producers and those clients who explicitly choose to monitor votes. backwards compatibility this eip is not forward compatible and introduces backwards incompatibilities in the state, fork choice rule, block reward, transaction validity, and gas calculations on certain transactions. therefore, all changes should be included in a scheduled hardfork at hybrid_casper_fork_blknum. copyright copyright and related rights waived via cc0. citation please cite this document as: danny ryan (@djrtwo), chih-cheng liang (@chihchengliang), "eip-1011: hybrid casper ffg [draft]," ethereum improvement proposals, no. 1011, april 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1011. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1571: ethereumstratum/2.0.0 ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-1571: ethereumstratum/2.0.0 authors andrea lanfranchi (@andrealanfranchi), pawel bylica (@chfast), marius van der wijden (@mariusvanderwijden) created 2018-11-09 discussion link https://github.com/andrealanfranchi/ethereumstratum-2.0.0/issues table of contents abstract conventions rationale stratum design flaws sources of inspiration specification json-rpc-2.0 compliances json-rpc-2.0 defiances conventions requests responses notifications protocol flow session handling hello session handling bye session handling session subscription session handling response to subscription session handling noop session handling reconnect workers authorization prepare for mining a detail of “extranonce” jobs notification solution submission hashrate copyright abstract this draft contains the guidelines to define a new standard for the stratum protocol used by ethereum miners to communicate with mining pool servers. conventions the key words must, must not, required, shall, shall not, should, should not, recommended, may, and optional in this document are to be interpreted as described in rfc 2119. the definition mining pool server, and it’s plural form, is to be interpreted as work provider and later in this document can be shortened as pool or server. the definition miner(s), and it’s plural form, is to be interpreted as work receiver/processor and later in this document can be shortened as miner or client. rationale ethereum does not have an official stratum implementation yet. it officially supports only getwork which requires miners to constantly pool the work provider. only recently go-ethereum have implemented a push mechanism to notify clients for mining work, but whereas the vast majority of miners do not run a node, it’s main purpose is to facilitate mining pools rather than miners. the stratum protocol on the other hand relies on a standard stateful tcp connection which allows two-way exchange of line-based messages. each line contains the string representation of a json object following the rules of either json-rpc 1.0 or json-rpc 2.0. unfortunately, in absence of a well defined standard, various flavours of stratum have bloomed for ethereum mining as a derivative work for different mining pools implementations. the only attempt to define a standard was made by nicehash with their ethereumstratum/1.0.0 implementation which is the main source this work inspires from. mining activity, thus the interaction among pools and miners, is at it’s basics very simple, and can be summarized with “please find a number (nonce) which coupled to this data as input for a given hashing algorithm produces, as output, a result which is below a certain target”. other messages which may or have to be exchanged among parties during a session are needed to support this basic concept. due to the simplicity of the subject, the proponent, means to stick with json formatted objects rather than investigating more verbose solutions, like for example google’s protocol buffers which carry the load of strict object definition. stratum design flaws the main stratum design flaw is the absence of a well defined standard. this implies that miners (and mining software developers) have to struggle with different flavours which make their life hard when switching from one pool to another or even when trying to “guess” which is the flavour implemented by a single pool. moreover all implementations still suffer from an excessive verbosity for a chain with a very small block time like ethereum. a few numbers may help understand. a normal mining.notify message weigh roughly 240 bytes: assuming the dispatch of 1 work per block to an audience of 50k connected tcp sockets means the transmission of roughly 1.88tb of data a month. and this can be an issue for large pools. but if we see the same figures the other way round, from a miner’s perspective, we totally understand how mining decentralization is heavily affected by the quality of internet connections. sources of inspiration nicehash ethereumstratum/1.0.0 zcash variant of the stratum protocol specification the stratum protocol is an instance of json-rpc-2.0. the miner is a json-rpc client, and the server is a json-rpc server. all communications exist within the scope of a session. a session starts at the moment a client opens a tcp connection to the server till the moment either party do voluntary close the very same connection or it gets broken. servers may support session resuming if this is initially negotiated (on first session handshaking) between the client and the server. during a session all messages exchanged among server and client are line-based which means all messages are json strings terminated by ascii lf character (which may also be denoted as \n in this document). the lf character must not appear elsewhere in a message. client and server implementations must assume that once they read a lf character, the current message has been completely received and can be processed. line messages are of three types : requests : messages for which the issuer expects a response. the receiver must reply back to any request individually responses : solicited messages by a previous request. the responder must label the response with the same identifier of the originating request. notifications : unsolicited messages for which the issuer is not interested nor is expecting a response. nevertheless a response (eg. an aknowledgement) may be sent by the receiver. during a session both parties can exchange messages of the above depicted three types. json-rpc-2.0 compliances as per json-rpc-2.0 specification requests and responses differ from notifications by the identifier (id) member in the json object: requests must have an id member responses must have an id member valued exactly as the id member of the request this response is for notifications must not have an id member json-rpc-2.0 defiances in order to get the most concise messages among parties of a session/conversation this implementation enforces the following defiances : json member jsonrpc (always valued to “2.0”) must always be omitted json member id must not be null. when member is present, mandatorily in requests and responses, it must be valued to an integer number ranging from 0 to 65535. please note that a message with "id": 0 must not be interpreted as a notification: it’s a request with identifier 0 json member id must be only of type primitive number. the removal of other identifier types (namely strings) is due to the need to reduce the number of bytes transferred. conventions the representation of a json object is, at it’s base, a string the conversation among the client and the server is made of strings. each string ending with a lf (ascii char 10) denotes a line. each line must contain only one json root object. eventually the root object may contain additional json objects in it’s members. aside the lf delimiter each line must be made of printable ascii chars in the range 32..126 it’s implicit and mandatory that each line message corresponds to a well formatted json object: see json documentation json objects are made of members which can be of type : primitive of string/number, json object, json arrays json member’s names are strings which must be composed of printable chars only in the ascii range 48..57 (numbers) and 97..122 (lower case letters). json member’s names must not begin with a number. json values arrays : although the json notation allows the insertion of different data types within the same array, this behavior is generally not accepted in coding languages. due to this, by the means of ethereumstratum/2.0.0, all implementers must assume that an array is made of elements of the very same data type. json values booleans : the json notation allows to express boolean values as true or false. in ethereumstratum/2.0.0, for better compatibility within arrays, boolean values will be expressed in the hex form of “0” (false) or “1” (true) json values strings : any string value must be composed of printable ascii chars only in the ascii range 32..126. each string is delimited by a " (ascii 34) at the beginning and at the end. should the string value contain a " this must be escaped as \" hex values : a hexadecimal representation of a number is actually a string data type. as a convention, and to reduce the number of transmitted bytes, the prefix “0x” must always be omitted. in addition any hex number must be transferred only for their significant part i.e. the non significant zeroes must be omitted (example : the decimal 456 must be represented as "1c8" and not as "01c8" although the conversion produces the same decimal value). this directive does not apply to hashes and extranonces hex values casing : all letters in hexadecimal values must be lower case. (example : the decimal 456 must be represented as "1c8" and not as "1c8" although the conversion produces the same decimal value). this directive does not apply to hashes. numbers : any non-fractional number must be transferred by it’s hexadecimal representation requests the json representation of request object is made of these parts: mandatory id member of type integer : the identifier established by the issuer mandatory method member of type string : the name of the method to be invoked on the receiver side optional params member : in case the method invocation on the receiver side requires the application of additional parameters to be executed. the type can be object (with named members of different types) or array of single type. in case of an array the parameters will be applied by their ordinal position. if the method requested for invocation on the receiver side does not require the application of additional parameters this member must not be present. the notation "params" : null is not permitted responses the json representation of response object is made of these parts: mandatory id member of type integer : the identifier of the request this response corresponds to optional error member : whether an error occurred during the parsing of the method or during it’s execution this member must be present and valued. if no errors occurred this member must not be present. for a detailed structure of the error member see below. optional result member : this has to be set, if the corresponding request requires a result from the user. if no errors occurred by invoking the corresponding function, this member must be present even if one or more information are null. the type can be of object or single type array or primitive string/number. if no data is meant back for the issuer (the method is void on the receiver) or an error occurred this member must not be present. you’ll notice here some differences with standard json-rpc-2.0. namely the result member is not always required. basically a response like this : {"id": 2} means “request received and processed correctly with no data to send back”. to better clarify the concept and clear the field of free interpretations let’s take another example of wrong response {"id": 2, "result": false} this response syntax leaves room to many interpretations : is it an error ? is false the legit response value to the issued request ? for this reason responses, we reiterate, must be of two types: success responses : no error occurred during the processing, the request was legit, syntactically correct, and the receiver had no issues processing it. this kind of responses must not have the error member and may have the result member if a value is expected back to the issuer. failure responses : something wrong with the request, it’s syntax, it’s validity scope, or server processing problems. this kind of responses must have the error member and may have the result member. the latter deserves a better explanation: failure responses can be distinguished by a severity degree. example 1 : a client submits a solution and server rejects it cause it’s not below target. server must respond like this { "id": 31, "error": { "code": 406, "message" : "bad nonce" } } example 2 : a client submits a solution and server accepts it but it accounts the share as stale. server must respond like this { "id": 31, "error": { "code": 202, "message" : "stale" } } example 3 : a client submits an authorization request specifying an invalid workername. server authorizes the account but rejects worker name. server must respond like this { "id": 1, "error": { "code": 215, "message" : "invalid worker name" } } example 1 depicts the condition of a severe failure while example 2 and 3 depict a situation where the request has been accepted and processed properly but the result may not be what expected by the client. it’s up to the client to evaluate the severity of the error and decide whether to proceed or not. using proper error codes pools may properly inform miners of the condition of their requests. error codes must honor this scheme: error codes 2xx : request accepted and processed but some additional info in the error member may give hint error codes 3xx : server could not process the request due to a lack of authorization by the client error codes 4xx : server could not process the request due to syntactic problems (method not found, missing params, wrong data types ecc.) or passed param values are not valid. error codes 5xx : server could not process the request due to internal errors notifications a notification message has the very same representation of a request with the only difference the id member must not be present. this means the issuer is not interested nor expects any response to this message. it’s up to the receiver to take actions accordingly. for instance the receiver may decide to execute the method, or, in case of errors or methods not allowed, drop the connection thus closing the session. error member as seen above a response may contain an error member. when present this member must be an object with: mandatory member code : a number which identifies the error occurred mandatory member message : a short human readable sentence describing the error occurred optional member data : a structured or primitive value that contains additional information about the error. the value of this member is defined by the server (e.g. detailed error information, nested errors etc.). protocol flow client starts session by opening a tcp socket to the server client advertises and request protocol compatibility server confirms compatibility and declares ready client starts/resumes a session client sends request for authorization for each of it’s workers server replies back with responses for each authorization server sends mining.set for constant values to be adopted for following mining jobs server sends mining.notify with minimal job info client mines on job client sends mining.submit if any solution found for the job server replies whether solution is accepted server optionally sends mining.set for constant values to be adopted for following mining jobs (if something changed) server sends mining.notify with minimal job info … (continue) eventually either party closes session and tcp connection session handling hello one of the worst annoyances until now is that server, at the very moment of socket connection, does not provide any useful information about the stratum flavour implemented. this means the client has to start a conversation by iteratively trying to connect via different protocol flavours. this proposal amends the situation making mandatory for the server to advertise itself to the client. when a new client connects to the server, the server must send a mining.hello notification : it’s been noted that charging the server of the duty to advertise itself as first message of the conversation could potentially be harmful in respect of traffic amplification attacks using spoofed ip addresses or in traditional ddos attacks where an attacker need to spend very little resources to force the server to send a large packet back. for this reason the duty of first advertisement is kept on client which will issue a mining.hello request like this: { "id" : 0, "method": "mining.hello", "params": { "agent": "ethminer-0.17", "host" : "somemininigpool.com", "port" : "4d2", "proto": "ethereumstratum/2.0.0" } } the params member object has these mandatory members: agent (string) the mining software version host (string) the host name of the server this client is willing to connect to port (hex) the port number of the server this client is willing to connect to proto (string) which reports the stratum flavour requested and expected to be implemented by the server; the rationale behind sending host and port is it enables virtual hosting, where virtual pools or private urls might be used for ddos protection, but that are aggregated on stratum server backends. as with http, the server cannot trust the host string. the port is included separately to parallel the client.reconnect method (see below). if the server is prepared to start/resume a session with such requirements it must reply back with a response like this: { "id" : 0, "result": { "proto" : "ethereumstratum/2.0.0", "encoding" : "gzip", "resume" : "1", "timeout" : "b4", "maxerrors" : "5", "node" : "geth/v1.8.18-unstable-f08f596a/linux-amd64/go1.10.4" } } where the result is an object made of 5 mandatory members proto (string) which must match the exact version requested by the client encoding (string) which value states whether or not all next messages should be gzip compressed or not. possible values are “gzip” or “plain” resume (hex) which value states whether or not the host can resume a previously created session; timeout (hex) which reports the number of seconds after which the server is allowed to drop connection if no messages from the client maxerrors (hex) the maximum number of errors the server will bear before abruptly close connection node (string) the node software version underlying the pool when the server replies back with "encoding" : "gzip" to the client, both parties must gzip compress all next messages. in case the client is not capable of compression it must close the connection immediately. should the server, after this reply, receive other messages as plain text, it must close the connection. eventually the client will continue with mining.subscribe (further on descripted) otherwise, in case of errors or rejection to start the conversation, the server may reply back with an error giving the other party useful information or, at server’s maintainers discretion, abruptly close the connection. { "id" : 0, "error": { "code": 400, "message" : "bad protocol request" } } or { "id" : 0, "error": { "code": 403, "message" : "forbidden banned ip address" } } the above two json error values are only samples eventually the server will close the connection. why a pool should advertise the node’s version ? it’s a matter of transparency : miners should know whether or not pool have upgraded to latest patches/releases for node’s software. session handling bye disconnection are not gracefully handled in stratum. client disconnections from pool may be due to several errors and this leads to waste of tcp sockets on server’s side which wait for keepalive timeouts to trigger. a useful notification is mining.bye which, once processed, allows both parties of the session to stop receiving and gracefully close tcp connections { "method": "mining.bye" } the party receiving this message aknowledges the other party wants to stop the conversation and closes the socket. the issuer will close too. the explicit issuance of this notification implies the session gets abandoned so no session resuming will be possible even on server which support session-resuming. client reconnecting to the same server which implements session resuming should expect a new session id and must re-authorize all their workers. session handling session subscription after receiving the response to mining.hello from server, the client, in case the server does support session resuming may request to resume a previously interrupted session with mining.subscribe request: { "id": 1, "method": "mining.subscribe", "params": "s-12345" } where params is the id of the session the client wants to resume. otherwise, if client wants to start a new session or server does not support session resuming, the request of subscription must omit the params member: { "id": 1, "method": "mining.subscribe" } session handling response to subscription a server receiving a client session subscription must reply back with { "id": 1, "result": "s-12345" } a server receiving a subscription request with params being a string holding the session id. this cases may apply if session resuming is not supported result will hold a new session id which must be a different value from the session member issued by client in previous mining.subscribe method if session resuming is supported it will retrieve working values from cache and result will have the same id requested by the client. this means a session is “resumed”: as a consequence the server can start pushing jobs omitting to precede them with mining.set (see below) and the client must continue to use values lastly received within the same session scope. in addition the client can omit to re-authorize all it’s workers. if session resuming is supported but the requested session has expired or it’s cache values have been purged result will hold a new session id which must be a different value from the session member issued by client in previous mining.subscribe method. as a consequence the server must wait for client to request authorization for it’s workers and must send mining.set values before pushing jobs. the client must prepare for a new session discarding all previously cached values (if any). a server implementing session-resuming must cache : the session ids any active job per session the extranonce any authorized worker servers may drop entries from the cache on their own schedule. it’s up to server to enforce session validation for same agent and/or ip. a client which successfully subscribes and resumes session (the session value in server response is identical to session value requested by client on mining.subscribe) can omit to issue the authorization request for it’s workers. session handling noop there are cases when a miner struggles to find a solution in a reasonable time so it may trigger the timeout imposed by the server in case of no communications (the server, in fact, may think the client got disconnected). to mitigate the problem a new method mining.noop(with no additional parameters) may be requested by the client. { "id": 50, "method": "mining.noop" } session handling reconnect under certain circumstances the server may need to free some resources and or to relocate miners to another machine. until now the only option for servers was to abruptly close the connection. on the miner’s side this action is interpreted as a server malfunction and they, more often than not, switch to a failover pool. the implementation of the notification mining.reconnect helps client to better merge with logic of handling of large mining pools. { "method": "mining.reconnect", "params": { "host": "someotherhost.com", "port": "d80", "resume": "1" } } this notification is meant only from servers to clients. should a server receive such a notification it will simply ignore it. after the notification has been properly sent, the server is allowed to close the connection, while the client will take the proper actions to reconnect to the suggested end-point. the host member in params object should report an host dns name and not an ip address: tls encrypted connections require to validate the cn name in the certificate which, 99% of the cases, is an host name. the third member resume of the params object sets whether or not the receiving server is prepared for session resuming. after this notification has been issued by the server, the client should expect no further messages and must disconnect. workers authorization the miner must authorize at least one worker in order to begin receiving jobs and submit solutions or hashrates. the miner may authorize multiple workers in the same session. the server must allow authorization for multiple workers within a session and must validate at least one authorization from the client before starting to send jobs. a worker is a tuple of the address where rewards must be credited coupled with identifier of the machine actually doing the work. for ethereum the most common form is .. the same account can be bound to multiple machines. for pool’s allowing anonymous mining the account is the address where rewards must be credited, while, for pools requiring registration, the account is the login name. each time a solution is submitted by the client it must be labelled with the worker identifier. it’s up to server to keep the correct accounting for different addresses. the syntax for the authorization request is the following: { "id": 2, "method": "mining.authorize", "params": ["[.]", "password"] } params member must be an array of 2 string elements. for anonymous mining the “password” can be any string value or empty but not null. pools allowing anonymous mining will simply ignore the value. the server must reply back either with an error or, in case of success, with { "id": 2, "result": "w-123" } where the result member is a string which holds an unique within the scope of the session token which identifies the authorized worker. for every further request issued by the client, and related to a worker action, the client must use the token given by the server in response to an mining.authorize request. this reduces the number of bytes transferred for solution and /or hashrate submission. if client is resuming a previous session it can omit the authorization request for it’s workers and, in this case, must use the tokens assigned in the originating session. it’s up to the server to keep the correct map between tokens and workers. the server receiving an authorization request where the credentials match previously authorized ones within the same session must reply back with the previously generated unique token. prepare for mining a lot of data is sent over the wire multiple times with useless redundancy. for instance the seed hash is meant to change only every 30000 blocks (roughly 5 days) while fixed-diff pools rarely change the work target. moreover pools must optimize the search segments among miners trying to assign to every session a different “startnonce” (aka extranonce). for this purpose the notification method mining.set allows to set (on miner’s side) only those params which change less frequently. the server will keep track of seed, target and extranonce at session level and will push a notification mining.set whenever any (or all) of those values change to the connected miner. { "method": "mining.set", "params": { "epoch" : "dc", "target" : "0112e0be826d694b2e62d01511f12a6061fbaec8bc02357593e70e52ba", "algo" : "ethash", "extranonce" : "af4c" } } at the beginning of each session the server must send this notification before any mining.notify. all values passed by this notification will be valid for all next jobs until a new mining.set notification overwrites them. description of members is as follows: optional epoch (hex) : unlike all actual stratum implementations the server should inform the client of the epoch number instead of passing the seed hash. this is enforced by two reasons : the main one is that client has only one way to compute the epoch number and this is by a linear search from epoch 0 iteratively trying increasing epochs till the hash matches the seed hash. second reason is that epoch number is more concise than seed hash. in the end the seed hash is only transmitted to inform the client about the epoch and is not involved in the mining algorithm. optional target (hex) : this is the boundary hash already adjusted for pool difficulty. unlike in ethereumstratum/1.0.0, which provides a mining.set_difficulty notification of an index of difficulty, the proponent opt to pass directly the boundary hash. if omitted the client must assume a boundary of "0x00000000ffff0000000000000000000000000000000000000000000000000000" optional algo (string) : the algorithm the miner is expected to mine on. if omitted the client must assume "algo": "ethash" optional extranonce (hex) : a starting search segment nonce assigned by server to clients so they possibly do not overlap their search segments. if server wants to “cancel” a previously set extranonce it must pass this member valued as an empty string. whenever the server detects that one, or two, or three or four values change within the session, the server will issue a notification with one, or two or three or four members in the param object. for this reason on each new session the server must pass all four members. as a consequence the miner is instructed to adapt those values on next job which gets notified. the new algo member is defined to be prepared for possible presence of algorithm variants to ethash, namely ethash1a or progpow. pools providing multicoin switching will take care to send a new mining.set to miners before pushing any job after a switch. the client which can’t support the data provided in the mining.set notification may close connection or stay idle till new values satisfy it’s configuration (see mining.noop). all client’s implementations must be prepared to accept new extranonces during the session: unlike in ethereumstratum/1.0.0 the optional client advertisement mining.extranonce.subscribe is now implicit and mandatory. the miner receiving the extranonce must initialize the search segment for next job resizing the extranonce to a hex of 16 bytes thus appending as many zeroes as needed. extranonce “af4c” means “search segment of next jobs starts from 0xaf4c000000000000” if extranonce is valued to an empty string, or it’s never been set within the session scope, the client is free pick any starting point of it’s own search segment on subsequent mining.notify jobs. a detail of “extranonce” miners connected to a pool might likely process the very same nonces thus wasting a lot of duplicate jobs. a nonce is any valid number which, applied to algorithm and job specifications, produces a result which is below a certain target. for every job pushed by server to client(s) there are 2^64 possible nonces to test. to be noted that : any nonce in the 2^64 has the very same possibility to be the right one. a certain hashing job can be solved by more than one nonce every “test” over a number is called a hash. assuming a miner should receive a job for each block and considering the actual average block time of 15 seconds that would mean a miner should try ( 2^64 / 15 ) / 1t ~ 1,229,782.94 terahashes per second this computation capacity is well beyond any miner on the market (including asics). for this reason single miners can process only small chunks (segments) of this humongous range. the way miners pick the segments to search on is beyond the scope of this work. fact is as miners are not coordinated there is no knowledge for a single miner of segments picked by other miners. extranonce concept is here to mitigate this possibility of duplicate jobs charging the server (the work provider) to give miners, at the maximum possible extent, different segments to search on. giving the above assumptions we can depict a nonce as any number in the hex range : min 0x0000000000000000 max 0xffffffffffffffff the prefix 0x is voluntarily inserted here only to give a better visual representation. the extranonce is, at it’s basics, the message of the server saying the client “i give you the first number to start search from”. more in detail the extranoce is the leftmost part of that number. assume a pool notifies the client the usage of extranonce ab5d this means the client will see it’s search segment narrowed as min 0xab5d000000000000 max 0xab5dffffffffffff pushing an extranonce of 4 bytes (like in the example) will give pool the possibility to separate segment 65535 different miners ( or if you prefer 0xffff miners ) while leaving the miner still a segment of 2^48 possible nonces to search on. recalculating, as above, the computation capacity needed to search this segment we get ( 2^48 / 15 ) / 1t ~ 18.76 terahashes per second which is still a wide segment where miners can randomly (or using other ergodic techniques) pick their internal search segments. extranonce must be passed with all relevant bytes (no omission of left zeroes) for a specific reason. assume an extranonce of “01ac” : it has the same decimal value of “1ac” but the number of bytes changes thus changing available search segment when "01ac" when "1ac" segment is segment is min 0x01ac000000000000 min 0x1ac0000000000000 max 0x01acffffffffffff max 0x1acfffffffffffff as you can see resulting segments are quite different this all said pools (server), when making use of extranonce, must observe a maximum length of 6 bytes (hex). jobs notification when available server will dispatch jobs to connected miners issuing a mining.notify notification. { "method": "mining.notify", "params": [ "bf0488aa", "6526d5" "645cf20198c2f3861e947d4f67e3ab63b7b2e24dcc9095bd9123e7b33371f6cc", "0" ] } params member is made of 4 mandatory elements: 1st element is jobid as specified by pool. to reduce the amount of data sent over the wire pools should keep their job ids as concise as possible. pushing a job id which is identical to headerhash is a bad practice and is highly discouraged. 2nd element is the hex number of the block id 3rd element is the headerhash. 4th element is an hex boolean indicating whether or not eventually found shares from previous jobs will be accounted for sure as stale. solution submission when a miner finds a solution for a job he is mining on it sends a mining.submit request to server. { "id": 31, "method": "mining.submit", "params": [ "bf0488aa", "68765fccd712", "w-123" ] } first element of params array is the jobid this solution refers to (as sent in the mining.notify message from the server). second element is the miner nonce as hex. third element is the token given to the worker previous mining.authorize request. any mining.submit request bound to a worker which was not successfully authorized i.e. the token does not exist in the session must be rejected. you’ll notice in the sample above the miner nonce is only 12 bytes wide (should be 16). why ? that’s because in the previous mining.set the server has set an extranonce of af4c. this means the full nonce is af4c68765fccd712 in presence of extranonce the miner must submit only the chars to append to the extranonce to build the final hex value. if no extranonce is set for the session or for the work the miner must send all 16 bytes. it’s server duty to keep track of the tuples job ids <-> extranonces per session. when the server receives this request it either responds success using the short form {"id": 31} or, in case of any error or condition with a detailed error object { "id": 31, "error": { "code": 404, "message" : "job not found" } } client should treat errors as “soft” errors (stales) or “hard” (bad nonce computation, job not found etc.). errors in 5xx range are server errors and suggest the miner to abandon the connection and switch to a failover. hashrate most pools offer statistic information, in form of graphs or by api calls, about the calculated hashrate expressed by the miner while miners like to compare this data with the hashrate they read on their devices. communication about parties of these information have never been coded in stratum and most pools adopt the method from getwork named eth_submithashrate. in this document we propose an official implementation of the mining.hashrate request. this method behaves differently when issued from client or from server. client communicates it’s hashrate to server. { "id" : 16, "method": "mining.hashrate", "params": [ "500000", "w-123" ] } where params is an array made of two elements: the first is a hexadecimal string representation (32 bytes) of the hashrate the miner reads on it’s devices and the latter is the authorization token issued to worker this hashrate is refers to (see above for mining.authorization). server must respond back with either an aknowledgment message {"id": 16 } optionally the server can reply back reporting it’s findings about calculated hashrate for the same worker. { "id": 16, "result" : [ "4f0000", "w-123" ] } in case of errors for example when the client submits too frequently with { "id": 16, "error" : { "code": 220, "message": "enhance your calm. too many requests" } } server communicates hashrate to client optionally the server can notify client about it’s overall performance (according to schedule set on server) with a mining.hashrate notification composed like this { "method": "mining.hashrate", "params": { "interval": 60, "hr": "500000", "accepted": [3692,20], "rejected": 0, } } where params is an object which holds these members for values of the whole session: interval (number) the width, in minutes, of the observation window. “in the last x minutes we calculated …” hr (hex) representation of the hashrate the pool has calculated for the miner accepted is an array of two number elements : the first is the overall count of accepted shares and the second is the number of stale shares. the array must be interpreted as “total accepted of which x are stale” rejected (number) the overall number of rejected shares the client will eventually take internal actions to reset/restart it’s workers. copyright copyright and related rights waived via cc0. citation please cite this document as: andrea lanfranchi (@andrealanfranchi), pawel bylica (@chfast), marius van der wijden (@mariusvanderwijden), "eip-1571: ethereumstratum/2.0.0 [draft]," ethereum improvement proposals, no. 1571, november 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1571. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. introducing ethereum script 2.0 | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search introducing ethereum script 2.0 posted by vitalik buterin on february 3, 2014 research & development this post will provide the groundwork for a major rework of the ethereum scripting language, which will substantially modify the way es works although still keeping many of the core components working in the exact same way. the rework is necessary as a result of multiple concerns which have been raised about the way the language is currently designed, primarily in the areas of simplicity, optimization, efficiency and future-compatibility, although it does also have some side-benefits such as improved function support. this is not the last iteration of es2; there will likely be many incremental structural improvements that can be made to the spec, but it does serve as a strong starting point. as an important clarification, this rework will have little effect on the ethereum cll, the stripped-down-python-like language in which you can write namecoin in five lines of code. the cll will still stay the same as it is now. we will need to make updates to the compiler (an alpha version of which is now available in python at http://github.com/ethereum/compiler or as a friendly web interface at http://162.218.208.138:3000) in order to make sure the cll continues to compile to new versions of es, but you as an ethereum contract developer working in e-cll should not need to see any changes at all. problems with es1 over the last month of working with es1, several problems with the language’s design have become apparent. in no particular order, they are as follows: too many opcodes – looking at the specification as it appears today, es1 now has exactly 50 opcodes – less than the 80 opcodes found in bitcoin script, but still far more than the theoretically minimal 4-7 opcodes needed to have a functional turing-complete scripting language. some of those opcodes are necessary because we want the scripting language to have access to a lot of data – for example, the transaction value, the transaction source, the transaction data, the previous block hash, etc; like it or not, there needs to be a certain degree of complexity in the language definition to provide all of these hooks. other opcodes, however, are excessive, and complex; as an example, consider the current definition of sha256 or ecverify. with the way the language is designed right now, that is necessary for efficiency; otherwise, one would have to write sha256 in ethereum script by hand, which might take many thousands of basefees. but ideally, there should be some way of eliminating much of the bloat. not future-compatible – the existence of the special crypto opcodes does make es1 much more efficient for certain specialized applications; thanks to them, computing sha3 takes only 40x basefee instead of the many thousands of basefees that it would take if sha3 was implemented in es directly; same with sha256, ripemd160 and secp256k1 elliptic curve operations. however, it is absolutely not future-compatible. even though these existing crypto operations will only take 40x basefee, sha4 will take several thousand basefees, as will ed25519 signatures, the quantum-proofntru, scip and zerocoin math, and any other constructs that will appear over the coming years. there should be some natural mechanism for folding such innovations in over time. not deduplication-friendly – the ethereum blockchain is likely to become extremely bloated over time, especially with every contract writing its own code even when the bulk of the code will likely be thousands of people trying to do the exact same thing. ideally, all instances where code is written twice should pass through some process of deduplication, where the code is only stored once and only a pointer to the code is stored twice. in theory, ethereum’s patricia trees do this already. in practice, however, code needs to be in exactly the same place in order for this to happen, and the existence of jumps means that it is often difficult to abitrarily copy/paste code without making appropriate modifications. furthermore, there is no incentivization mechanism to convince people to reuse existing code. not optimization-friendly – this is a very similar criterion to future-compatibility and deduplication-friendliness in some ways. however, here optimization refers to a more automatic process of detecting bits of code that are reused many times, and replacing them with memoized or compiled machine code versions. beginnings of a solution: deduplication the first issue that we can handle is that of deduplication. as described above, ethereum patricia trees provide deduplication already, but the problem is that achieving the full benefits of the deduplication requires the code to be formatted in a very special way. for example, if the code in contract a from index 0 to index 15 is the same as the code in contract b from index 48 to index 63, then deduplication happens. however, if the code in contract b is offset at all modulo 16 (eg. from index 49 to index 64), then no deduplication takes place at all. in order to remedy this, there is one relatively simple solution: move from a dumb hexary patricia tree to a more semantically oriented data structure. that is, the tree represented in the database should mirror the abstract syntax tree of the code. to understand what i am saying here, consider some existing es1 code: txvalue push 25 push 10 push 18 exp mul lt not push 14 jmpi stop push 0 txdata sload not push 0 txdata push 1000 lt not mul not not push 32 jmpi stop push 1 txdata push 0 txdata sstore in the patricia tree, it looks like this: ( (txvalue push 25 push 10 push 18 exp mul lt not push 14 jmpi stop push) (0 txdata sload not push 0 txdata push 1000 lt not mul not not push 32) (jmpi stop push 1 txdata push 0 txdata sstore) ) and here is what the code looks like structurally. this is easiest to show by simply giving the e-cll it was compiled from: if tx.value < 25 * 10^18: stop if contract.storage[tx.data[0]] or tx.data[0] < 1000: stop contract.storage[tx.data[0]] = tx.data[1] no relation at all. thus, if another contract wanted to use some semantic sub-component of this code, it would almost certainly have to re-implement the whole thing. however, if the tree structure looked somewhat more like this: ( ( if (txvalue push 25 push 10 push 18 exp mul lt not) (stop) ) ( if (push 0 txdata sload not push 0 txdata push 1000 lt not mul not) (stop) ) ( push 1 txdata push 0 txdata sstore ) ) then if someone wanted to reuse some particular piece of code they easily could. note that this is just an illustrative example; in this particular case it probably does not make sense to deduplicate since pointers need to be at least 20 bytes long to be cryptographically secure, but in the case of larger scripts where an inner clause might contain a few thousand opcodes it makes perfect sense. immutability and purely functional code another modification is that code should be immutable, and thus separate from data; if multiple contracts rely on the same code, the contract that originally controls that code should not have the ability to sneak in changes later on. the pointer to which code a running contract should start with, however, should be mutable. a third common optimization-friendly technique is the make a programming language purely functional, so functions cannot have any side effects outside of themselves with the exception of return values. for example, the following is a pure function: def factorial(n): prod = 1 for i in range(1,n+1): prod *= i return prod however, this is not: x = 0 def next_integer(): x += 1 return x and this most certainly is not: import os def happy_fluffy_function(): bal = float(os.popen('bitcoind getbalance').read()) os.popen('bitcoind sendtoaddress 1jwssubhmg6iptrjtyqhuyyh7bzg3lfy1t %.8f' % (bal 0.0001)) os.popen('rm -rf ~') ethereum cannot be purely functional, since ethereum contracts do necessarily have state – a contract can modify its long-term storage and it can send transactions. however, ethereum script is a unique situation because ethereum is not just a scripting environment – it is an incentivized scripting environment. thus, we can allow applications like modifying storage and sending transactions, but discourage them with fees, and thus ensure that most script components are purely functional simply to cut costs, even while allowing non-purity in those situations where it makes sense. what is interesting is that these two changes work together. the immutability of code also makes it easier to construct a restricted subset of the scripting language which is functional, and then such functional code could be deduplicated and optimized at will. ethereum script 2.0 so, what’s going to change? first of all, the basic stack-machine concept is going to roughly stay the same. the main data structure of the system will continue to be the stack, and most of your beloved opcodes will not change significantly. the only differences in the stack machine are the following: crypto opcodes are removed. instead, we will have to have someone write sha256, ripemd160, sha3 and ecc in es as a formality, and we can have our interpreters include an optimization replacing it with good old-fashioned machine-code hashes and sigs right from the start. memory is removed. instead, we are bringing back dupn (grabs the next value in the code, say n, and pushes a copy of the item n items down the stack to the top of the stack) and swapn (swaps the top item and the nth item). jmp and jmpi are removed. run, if, while and setroot are added (see below for further definition) another change is in how transactions are serialized. now, transactions appear as follows: send: [ 0, nonce, to, value, [ data0 ... datan ], v, r, s ] mkcode: [ 1, nonce, [ data0 ... datan ], v, r, s ] mkcontract: [ 2, nonce, coderoot, v, r, s ] the address of a contract is defined by the last 20 bytes of the hash of the transaction that produced it, as before. additionally, the nonce no longer needs to be equal to the nonce stored in the account balance representation; it only needs to be equal to or greater than that value. now, suppose that you wanted to make a simple contract that just keeps track of how much ether it received from various addresses. in e-cll that’s: contract.storage[tx.sender] = tx.value in es2, instantiating this contract now takes two transactions: [ 1, 0, [ txvalue txsender sstore ], v, r, s] [ 2, 1, 761fd7f977e42780e893ea44484c4b64492d8383, v, r, s ] what happens here is that the first transaction instantiates a code node in the patricia tree. the hash sha3(rlp.encode([ txvalue txsender sstore ]))[12:] is 761fd7f977e42780e893ea44484c4b64492d8383, so that is the “address” where the code node is stored. the second transaction basically says to initialize a contract whose code is located at that code node. thus, when a transaction gets sent to the contract, that is the code that will run. now, we come to the interesting part: the definitions of if and run. the explanation is simple: if loads the next two values in the code, then pops the top item from the stack. if the top item is nonzero, then it runs the code item at the first code value. otherwise, it runs the code item at the second code value. while is similar, but instead loads only one code value and keeps running the code while the top item on the stack is nonzero. finally, run just takes one code value and runs the code without asking for anything. and that’s all you need to know. here is one way to do a namecoin contract in new ethereum script: a: [ txvalue push 25 push 10 push 18 exp mul lt ] b: [ push 0 txdata sload not push 0 txdata push 100 lt not mul not ] z: [ stop ] y: [ ] c: [ push 1 txdata push 0 txdata sstore ] m: [ run a if z y run b if z y run c ] the contract would then have its root be m. but wait, you might say, this makes the interpreter recursive. as it turns out, however, it does not – you can simulate the recursion using a data structure called a “continuation stack”. here’s what the full stack trace of that code might look like, assuming the transaction is [ x, y ] sending v where x > 100, v > 10^18 * 25and contract.storage[x] is not set: { stack: [], cstack: [[m, 0]], op: run } { stack: [], cstack: [[m, 2], [a, 0]], op: txvalue } { stack: [v], cstack: [[m, 2], [a, 1]], op: push } { stack: [v, 25], cstack: [[m, 2], [a, 3]], op: push } { stack: [v, 25, 10], cstack: [[m, 2], [a, 5]], op: push } { stack: [v, 25, 10, 18], cstack: [[m, 2], [a, 7]], op: exp } { stack: [v, 25, 10^18], cstack: [[m, 2], [a, 8]], op: mul } { stack: [v, 25*10^18], cstack: [[m, 2], [a, 9]], op: lt } { stack: [0], cstack: [[m, 2], [a, 10]], op: null } { stack: [0], cstack: [[m, 2]], op: if } { stack: [0], cstack: [[m, 5], [y, 0]], op: null } { stack: [0], cstack: [[m, 5]], op: run } { stack: [], cstack: [[m, 7], [b, 0]], op: push } { stack: [0], cstack: [[m, 7], [b, 2]], op: txdata } { stack: [x], cstack: [[m, 7], [b, 3]], op: sload } { stack: [0], cstack: [[m, 7], [b, 4]], op: not } { stack: [1], cstack: [[m, 7], [b, 5]], op: push } { stack: [1, 0], cstack: [[m, 7], [b, 7]], op: txdata } { stack: [1, x], cstack: [[m, 7], [b, 8]], op: push } { stack: [1, x, 100], cstack: [[m, 7], [b, 10]], op: lt } { stack: [1, 0], cstack: [[m, 7], [b, 11]], op: not } { stack: [1, 1], cstack: [[m, 7], [b, 12]], op: mul } { stack: [1], cstack: [[m, 7], [b, 13]], op: not } { stack: [1], cstack: [[m, 7], [b, 14]], op: null } { stack: [0], cstack: [[m, 7]], op: if } { stack: [0], cstack: [[m, 9], [y, 0]], op: null } { stack: [], cstack: [[m, 10]], op: run } { stack: [], cstack: [[m, 12], [c, 0]], op: push } { stack: [1], cstack: [[m, 12], [c, 2]], op: txdata } { stack: [y], cstack: [[m, 12], [c, 3]], op: push } { stack: [y,0], cstack: [[m, 12], [c, 5]], op: txdata } { stack: [y,x], cstack: [[m, 12], [c, 6]], op: sstore } { stack: [], cstack: [[m, 12], [c, 7]], op: null } { stack: [], cstack: [[m, 12]], op: null } { stack: [], cstack: [], op: null } and that’s all there is to it. cumbersome to read, but actually quite easy to implement in any statically or dynamically types programming language or perhaps even ultimately in an asic. optimizations in the above design, there is still one major area where optimizations can be made: making the references compact. what the clear and simple style of the above contract hid is that those pointers to a, b, c, m and z aren’t just compact single letters; they are 20-byte hashes. from an efficiency standpoint, what we just did is thus actually substantially worse than what we had before, at least from the point of view of special cases where code is not nearly-duplicated millions of times. also, there is still no incentive for people writing contracts to write their code in such a way that other programmers later on can optimize; if i wanted to code the above in a way that would minimize fees, i would just put a, b and c into the contract directly rather than separating them out into functions. there are two possible solutions: instead of using h(x) = sha3(rlp.encode(x))[12:], use h(x) = sha3(rlp.encode(x))[12:] if len(rlp.encode(x)) >= 20 else x. to summarize, if something is less than 20 bytes long, we include it directly. a concept of “libraries”. the idea behind libraries is that a group of a few scripts can be published together, in a format [ [ ... code ... ], [ ... code ... ], ... ], and these scripts can internally refer to each other with their indices in the list alone. this completely alleviates the problem, but at some cost of harming deduplication, since sub-codes may need to be stored twice. some intelligent thought into exactly how to improve on this concept to provide both deduplication and reference efficiency will be required; perhaps one solution would be for the library to store a list of hashes, and then for the continuation stack to store [ lib, libindex, codeindex ] instead of [ hash, index ]. other optimizations are likely possible. for example, one important weakness of the design described above is that it does not support recursion, offering only while loops to provide turing-completeness. it might seem to, since you can call any function, but if you try to actually try to implement recursion in es2 as described above you soon notice that implementing recursion would require finding the fixed point of an iterated hash (ie. finding x such that h(a + h( c + ... h(x) ... + d) + b) = x), a problem which is generally assumed to be cryptographically impossible. the “library” concept described above does actually fix this at least internally to one library; ideally, a more perfect solution would exist, although it is not necessary. finally, some research should go into the question of making functions first-class; this basically means changing the if and runopcode to pull the destination from the stack rather than from fixed code. this may be a major usability improvement, since you can then code higher-order functions that take functions as arguments like map, but it may also be harmful from an optimization standpoint since code becomes harder to analyze and determine whether or not a given computation is purely functional. fees finally, there is one last question to be resolved. the primary purposes of es2 as described above are twofold: deduplication and optimization. however, optimizations by themselves are not enough; in order for people to actually benefit from the optimizations, and to be incentivized to code in patterns that are optimization-friendly, we need to have a fee structure that supports this. from a deduplication perspective, we already have this; if you are the second person to create a namecoin-like contract, and you want to use a, you can just link to a without paying the fee to instantiate it yourself. however, from an optimization perspective, we are far from done. if we create sha3 in es, and then have the interpreter intelligently replace it with a contract, then the interpreter does get much faster, but the person using sha3 still needs to pay thousands of basefees. thus, we need a mechanism for reducing the fee of specific computations that have been heavily optimized. our current strategy with fees is to have miners or ether holders vote on the basefee, and in theory this system can easily be expanded to include the option to vote on reduced fees for specific scripts. however, this does need to be done intelligently. for example, exp can be replaced with a contract of the following form: push 1 swapn 3 swap while ( dup push 2 mod if ( dupn 2 ) ( push 1 ) dupn 4 mul swapn 4 pop 2 div swap dup mul swap ) pop however, the runtime of this contract depends on the exponent – with an exponent in the range [4,7] the while loop runs three times, in the range [1024, 2047] the while loop runs eleven times, and in the range [2^255, 2^256-1] it runs 256 times. thus, it would be highly dangerous to have a mechanism which can be used to simply set a fixed fee for any contract, since that can be exploited to, say, impose a fixed fee for a contract computing the ackermann function (a function notorious in the world of mathematics because the cost of computing or writing down its output grows so fast that with inputs as low as 5 it becomes larger than the size of the universe). thus, a percentage discount system, where some contracts can enjoy half as large a basefee, may make more sense. ultimately, however, a contract cannot be optimized down to below the cost of calling the optimized code, so we may want to have a fixed fee component. a compromise approach might be to have a discount system, but combined with a rule that no contract can have its fee reduced below 20x the basefee. so how would fee voting work? one approach would be to store the discount of a code item along side that code item’s code, as a number from 1 to 232, where 232 represents no discount at all and 1 represents the highest discounting level of 4294967296x (it may be prudent to set the maximum at 65536x instead for safety). miners would be authorized to make special “discount transactions” changing the discounting number of any code item by a maximum of 1/65536x of its previous value. with such a system, it would take about 40000 blocks or about one month to halve the fee of any given script, a sufficient level of friction to prevent mining attacks and give everyone a chance to upgrade to new clients with more advanced optimizers while still making it possible to update fees as required to ensure future-compatibility. note that the above description is not clean, and is still very much not fleshed out; a lot of care will need to be made in making it maximally elegant and easy to implement. an important point is that optimizers will likely end up replacing entire swaths of es2 code blocks with more efficient machine code, but under the system described above will still need to pay attention to es2 code blocks in order to determine what the fee is. one solution is to have a miner policy offering discounts only to contracts which maintain exactly the same fee when run regardless of their input; perhaps other solutions exist as well. however, one thing is clear: the problem is not an easy one. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-5005: zodiac modular accounts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5005: zodiac modular accounts composable interoperable programmable accounts authors auryn macmillan (@auryn-macmillan), kei kreutler (@keikreutler) created 2022-04-14 discussion link https://ethereum-magicians.org/t/eip-zodiac-a-composable-design-philosophy-for-daos/8963 requires eip-165 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip standardizes interfaces for composable and interoperable tooling for programmable ethereum accounts. these interfaces separate contract accounts (“avatars”) from their authentication and execution logic (“guards” and “modules”). avatars implement the iavatar interface, and guards implement the iguard interface. modules may take any form. motivation currently, most programmable accounts (like dao tools and frameworks) are built as monolithic systems where the authorization and execution logic are coupled, either within the same contract or in a tightly integrated system of contracts. this needlessly inhibits the flexibility of these tools and encourages platform lock-in via high switching costs. by using the this eip standard to separate concerns (decoupling authentication and execution logic), users are able to: enable flexible, module-based control of programmable accounts easily switch between tools and frameworks without unnecessary overhead. enable multiple control mechanism in parallel. enable cross-chain / cross-layer governance. progressively decentralize their governance as their project and community matures. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. this eip consists of four key concepts: avatars are programmable ethereum accounts. avatars are the address that holds balances, owns systems, executes transaction, is referenced externally, and ultimately represents your dao. avatars must implement the iavatar interface. modules are contracts enabled by an avatar that implement some execution logic. modifiers are contracts that sit between modules and avatars to modify the module’s behavior. for example, they might enforce a delay on all functions a module attempts to execute or limit the scope of transactions that can be initiated by the module. modifiers must implement the iavatar interface. guards are contracts that may be enabled on modules or modifiers and implement preor post-checks on each transaction executed by those modules or modifiers. this allows avatars to do things like limit the scope of addresses and functions that a module or modifier can call or ensure a certain state is never changed by a module or modifier. guards must expose the iguard interface. modules, modifiers, and avatars that wish to be guardable must inherit guardable, must call checktransaction() before triggering execution on their target, and must call checkafterexecution() after execution is complete. /// @title avatar a contract that manages modules that can execute transactions via this contract. pragma solidity >=0.7.0 <0.9.0; import "./enum.sol"; interface iavatar { event enabledmodule(address module); event disabledmodule(address module); event executionfrommodulesuccess(address indexed module); event executionfrommodulefailure(address indexed module); /// @dev enables a module on the avatar. /// @notice can only be called by the avatar. /// @notice modules should be stored as a linked list. /// @notice must emit enabledmodule(address module) if successful. /// @param module module to be enabled. function enablemodule(address module) external; /// @dev disables a module on the avatar. /// @notice can only be called by the avatar. /// @notice must emit disabledmodule(address module) if successful. /// @param prevmodule address that pointed to the module to be removed in the linked list /// @param module module to be removed. function disablemodule(address prevmodule, address module) external; /// @dev allows a module to execute a transaction. /// @notice can only be called by an enabled module. /// @notice must emit executionfrommodulesuccess(address module) if successful. /// @notice must emit executionfrommodulefailure(address module) if unsuccessful. /// @param to destination address of module transaction. /// @param value ether value of module transaction. /// @param data data payload of module transaction. /// @param operation operation type of module transaction: 0 == call, 1 == delegate call. function exectransactionfrommodule( address to, uint256 value, bytes memory data, enum.operation operation ) external returns (bool success); /// @dev allows a module to execute a transaction and return data /// @notice can only be called by an enabled module. /// @notice must emit executionfrommodulesuccess(address module) if successful. /// @notice must emit executionfrommodulefailure(address module) if unsuccessful. /// @param to destination address of module transaction. /// @param value ether value of module transaction. /// @param data data payload of module transaction. /// @param operation operation type of module transaction: 0 == call, 1 == delegate call. function exectransactionfrommodulereturndata( address to, uint256 value, bytes memory data, enum.operation operation ) external returns (bool success, bytes memory returndata); /// @dev returns if an module is enabled /// @return true if the module is enabled function ismoduleenabled(address module) external view returns (bool); /// @dev returns array of modules. /// @param start start of the page. /// @param pagesize maximum number of modules that should be returned. /// @return array array of modules. /// @return next start of the next page. function getmodulespaginated(address start, uint256 pagesize) external view returns (address[] memory array, address next); } pragma solidity >=0.7.0 <0.9.0; import "./enum.sol"; interface iguard { function checktransaction( address to, uint256 value, bytes memory data, enum.operation operation, uint256 safetxgas, uint256 basegas, uint256 gasprice, address gastoken, address payable refundreceiver, bytes memory signatures, address msgsender ) external; function checkafterexecution(bytes32 txhash, bool success) external; } pragma solidity >=0.7.0 <0.9.0; import "./enum.sol"; import "./baseguard.sol"; /// @title guardable a contract that manages fallback calls made to this contract contract guardable { address public guard; event changedguard(address guard); /// `guard_` does not implement ierc165. error notierc165compliant(address guard_); /// @dev set a guard that checks transactions before execution. /// @param _guard the address of the guard to be used or the 0 address to disable the guard. function setguard(address _guard) external { if (_guard != address(0)) { if (!baseguard(_guard).supportsinterface(type(iguard).interfaceid)) revert notierc165compliant(_guard); } guard = _guard; emit changedguard(guard); } function getguard() external view returns (address _guard) { return guard; } } pragma solidity >=0.7.0 <0.9.0; import "./enum.sol"; import "./ierc165.sol"; import "./iguard.sol"; abstract contract baseguard is ierc165 { function supportsinterface(bytes4 interfaceid) external pure override returns (bool) { return interfaceid == type(iguard).interfaceid || // 0xe6d7a83a interfaceid == type(ierc165).interfaceid; // 0x01ffc9a7 } /// @dev module transactions only use the first four parameters: to, value, data, and operation. /// module.sol hardcodes the remaining parameters as 0 since they are not used for module transactions. function checktransaction( address to, uint256 value, bytes memory data, enum.operation operation, uint256 safetxgas, uint256 basegas, uint256 gasprice, address gastoken, address payable refundreceiver, bytes memory signatures, address msgsender ) external virtual; function checkafterexecution(bytes32 txhash, bool success) external virtual; } pragma solidity >=0.7.0 <0.9.0; /// @title enum collection of enums contract enum { enum operation {call, delegatecall} } rationale the interface defined in this standard is designed to be mostly compatible with most popular programmable accounts in use right now, to minimize the need for changes to existing tooling. backwards compatibility no backward compatibility issues are introduced by this standard. security considerations there are some considerations that module developers and users should take into account: modules have absolute control: modules have absolute control over any avatar on which they are enabled, so any module implementation should be treated as security critical and users should be vary cautious about enabling new modules. only enable modules that you trust with the full value of the avatar. race conditions: a given avatar may have any number of modules enabled, each with unilateral control over the safe. in such cases, there may be race conditions between different modules and/or other control mechanisms. don’t brick your avatar: there are no safeguards to stop you adding or removing modules. if you remove all of the modules that let you control an avatar, the avatar will cease to function and all funds will be stuck. copyright copyright and related rights waived via cc0. citation please cite this document as: auryn macmillan (@auryn-macmillan), kei kreutler (@keikreutler), "erc-5005: zodiac modular accounts [draft]," ethereum improvement proposals, no. 5005, april 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5005. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6963: multi injected provider discovery ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: interface eip-6963: multi injected provider discovery using window events to announce injected wallet providers authors pedro gomes (@pedrouid), kosala hemachandra (@kvhnuke), richard moore (@ricmoo), gregory markou (@gregthegreek), kyle den hartog (@kdenhartog), glitch (@glitch-txs), jake moxey (@jxom), pierre bertet (@bpierre), darryl yeo (@darrylyeo), yaroslav sergievsky (@everdimension) created 2023-05-01 requires eip-1193 table of contents abstract motivation specification definitions provider info provider detail window events rationale interfaces backwards compatibility reference implementation wallet provider dapp implementation security considerations eip-1193 security considerations prototype pollution of wallet provider objects wallet imitation and manipulation prevent svg javascript execution prevent wallet fingerprinting copyright abstract an alternative discovery mechanism to window.ethereum for eip-1193 providers which supports discovering multiple injected wallet providers in a web page using javascript’s window events. motivation currently, wallet provider that offer browser extensions must inject their ethereum providers (eip-1193) into the same window object window.ethereum; however, this creates conflicts for users that may install more than one browser extension. browser extensions are loaded in the web page in an unpredictable and unstable order, resulting in a race condition where the user does not have control over which wallet provider is selected to expose the ethereum interface under the window.ethereum object. instead, the last wallet to load usually wins. this results not only in a degraded user experience but also increases the barrier to entry for new browser extensions as users are forced to only install one browser extension at a time. some browser extensions attempt to counteract this problem by delaying their injection to overwrite the same window.ethereum object which creates an unfair competition for wallet providers and lack of interoperability. in this proposal, we present a solution that focuses on optimizing the interoperability of multiple wallet providers. this solution aims to foster fairer competition by reducing the barriers to entry for new wallet providers, along with enhancing the user experience on ethereum networks. this is achieved by introducing a set of window events to provide a two-way communication protocol between ethereum libraries and injected scripts provided by browser extensions thus enabling users to select their wallet of choice. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc-2119. definitions wallet provider: a user agent that manages keys and facilitates transactions with ethereum. decentralized application (dapp): a web page that relies upon one or many web3 platform apis which are exposed to the web page via the wallet. provider discovery library: a library or piece of software that assists a dapp to interact with the wallet. provider info each wallet provider will be announced with the following interface eip6963providerinfo. the values in the eip6963providerinfo must be included within the eip6963providerinfo object. the eip6963providerinfo may also include extra extensible properties within the object. if a dapp does not recognize the additional properties, it should ignore them. uuid a globally unique identifier the wallet provider that must be (uuidv4 compliant) to uniquely distinguish different eip-1193 provider sessions that have matching properties defined below during the lifetime of the page. the cryptographic uniqueness provided by uuidv4 guarantees that two independent eip6963providerinfo objects can be separately identified. name a human-readable local alias of the wallet provider to be displayed to the user on the dapp. (e.g. example wallet extension or awesome example wallet) icon a uri pointing to an image. the image should be a square with 96x96px minimum resolution. see the images/icons below for further requirements of this property. rdns the wallet must supply the rdns property which is intended to be a domain name from the domain name system in reverse syntax ordering such as com.example.subdomain. it’s up to the wallet to determine the domain name they wish to use, but it’s generally expected the identifier will remain the same throughout the development of the wallet. it’s also worth noting that similar to a user agent string in browsers, there are times where the supplied value could be unknown, invalid, incorrect, or attempt to imitate a different wallet. therefore, the dapp should be able to handle these failure cases with minimal degradation to the functionality of the dapp. /** * represents the assets needed to display a wallet */ interface eip6963providerinfo { uuid: string; name: string; icon: string; rdns: string; } images/icons a uri-encoded image was chosen to enable flexibility for multiple protocols for fetching and rendering icons, for example: # svg (data uri) data:image/svg+xml, # png (data uri) data:image/png;base64,ivborw0kggoaaaansuheugaaaauaaaafcayaaacnbyblaaaaheleqvqi12p4//8/w38giaxdibke0dhxgljnbaao9txl0y4ohwaaaabjru5erkjggg== the icon string must be a data uri as defined in rfc-2397. the image should be a square with 96x96px minimum resolution. the image format is recommended to be either lossless or vector based such as png, webp or svg to make the image easy to render on the dapp. since svg images can execute javascript, applications and libraries must render svg images using the tag to ensure no untrusted javascript execution can occur. rdns the rdns (reverse-dns) property serves to provide an identifier which dapps can rely on to be stable between sessions. the reverse domain name notation is chosen to prevent namespace collisions. the reverse-dns convention implies that the value should start with a reversed dns domain name controlled by the provider. the domain name should be followed by a subdomain or a product name. example: com.example.mybrowserwallet. the rdns value must be a valid rfc-1034 domain name; the dns part of the rdns value should be an active domain controlled by the provider; dapps may reject the providers which do not follow the reverse-dns convention correctly; dapps should not use the rnds value for feature detection as these are self-attested and prone to impersonation or bad incentives without an additional verification mechanism; feature-discovery and verification are both out of scope of this interface specification. provider detail the eip6963providerdetail is used as a composition interface to announce a wallet provider and related metadata about the wallet provider. the eip6963providerdetail must contain an info property of type eip6963providerinfo and a provider property of type eip1193provider defined by eip-1193. interface eip6963providerdetail { info: eip6963providerinfo; provider: eip1193provider; } window events in order to prevent provider collisions, the dapp and the wallet are expected to emit an event and instantiate an eventlistener to discover the various wallets. this forms an event concurrency loop. since the dapp code and wallet code aren’t guaranteed to run in a particular order, the events are designed to handle such race conditions. to emit events, both dapps and wallets must use the window.dispatchevent function to emit events and must use the window.addeventlistener function to observe events. there are two event interfaces used for the dapp and wallet to discover each other. announce and request events the eip6963announceproviderevent interface must be a customevent object with a type property containing a string value of eip6963:announceprovider and a detail property with an object value of type eip6963providerdetail. the eip6963providerdetail object should be frozen by calling object.freeze() on the value of the detail property. // announce event dispatched by a wallet interface eip6963announceproviderevent extends customevent { type: "eip6963:announceprovider"; detail: eip6963providerdetail; } the eip6963requestproviderevent interface must be an event object with a type property containing a string value of eip6963:requestprovider. // request event dispatched by a dapp interface eip6963requestproviderevent extends event { type: "eip6963:requestprovider"; } the wallet must announce the eip6963announceproviderevent to the dapp via a window.dispatchevent() function call. the wallet must add an eventlistener to catch an eip6963requestproviderevent dispatched from the dapp. this eventlistener must use a handler that will re-dispatch an eip6963announceproviderevent. this re-announcement by the wallet is useful for when a wallet’s initial event announcement may have been delayed or fired before the dapp had initialized its eventlistener. this allows the various wallet providers to react to the dapp without the need to pollute the window.ethereum namespace which can produce non-deterministic wallet behavior such as different wallets connecting each time. the wallet dispatches the "eip6963:announceprovider" event with immutable contents and listens to the "eip6963:requestprovider" event: let info: eip6963providerinfo; let provider: eip1193provider; const announceevent: eip6963announceproviderevent = new customevent( "eip6963:announceprovider", { detail: object.freeze({ info, provider }) } ); // the wallet dispatches an announce event which is heard by // the dapp code that had run earlier window.dispatchevent(announceevent); // the wallet listens to the request events which may be // dispatched later and re-dispatches the `eip6963announceproviderevent` window.addeventlistener("eip6963:requestprovider", () => { window.dispatchevent(announceevent); }); the dapp must listen for the eip6963announceproviderevent dispatched by the wallet via a window.addeventlistener() method and must not remove the event listener for the lifetime of the page so that the dapp can continue to handle events beyond the initial page load interaction. the dapp must dispatch the eip6963requestproviderevent via a window.dispatchevent() function call after the eip6963announceproviderevent handler has been initialized. // the dapp listens to announced providers window.addeventlistener( "eip6963:announceprovider", (event: eip6963announceproviderevent) => {} ); // the dapp dispatches a request event which will be heard by // wallets' code that had run earlier window.dispatchevent(new event("eip6963:requestprovider")); the dapp may elect to persist various eip6963providerdetail objects contained in the announcement events sent by multiple wallets. thus, if the user wishes to utilize a different wallet over time, the user can express this within the dapp’s interface and the dapp can immediately elect to send transactions to that new wallet. otherwise, the dapp may re-initiate the wallet discovery flow via dispatching a new eip6963requestproviderevent, potentially discovering a different set of wallets. the described orchestration of events guarantees that the dapp is able to discover the wallet, regardless of which code executes first, the wallet code or the dapp code. rationale the previous proposal introduced mechanisms that relied on a single, mutable window object that could be overwritten by multiple parties. we opted for an event-based approach to avoid the race conditions, the namespace collisions, and the potential for “pollution” attacks on a shared mutable object; the event-based orchestration creates a bidirectional communication channel between wallet and dapp that can be re-orchestrated over time. to follow the javascript event name conventions, the names are written in present tense and are prefixed with the number of this document (eip6963). interfaces standardizing an interface for provider information (eip6963providerinfo) allows a dapp to determine all information necessary to populate a user-friendly wallet selection modal. this is particularly useful for dapps that rely on libraries such as web3modal, rainbowkit, web3-onboard, or connectkit to programmatically generate such selection modals. regarding the announced provider interface (eip6963providerdetail), it was important to leave the eip-1193 provider interface untouched for backwards compatibility; this allows conformant dapps to interface with wallets conforming to either, and for wallets conformant to this spec to still inject eip-1193 providers for legacy dapps. note that a legacy dapp or a dapp conformant with this spec connecting to a legacy wallet cannot guarantee the correct wallet will be selected if multiple are present. backwards compatibility this eip doesn’t require supplanting window.ethereum, so it doesn’t directly break existing applications that cannot update to this method of wallet discovery. however, it is recommended dapps implement this eip to ensure discovery of multiple wallet providers and should disable window.ethereum usage except as a fail-over when discovery fails. similarly, wallets should keep compatibility of window.ethereum to ensure backwards compatibility for dapps that have not implemented this eip. in order to prevent the previous issues of namespace collisions, it’s also recommended that wallets inject their provider object under a wallet specific namespace then proxy the object into the window.ethereum namespace. reference implementation wallet provider here is a reference implementation for an injected script by a wallet provider to support this new interface in parallel with the existing pattern. function onpageload() { let provider: eip1193provider; window.ethereum = provider; function announceprovider() { const info: eip6963providerinfo = { uuid: "350670db-19fa-4704-a166-e52e178b59d2", name: "example wallet", icon: "data:image/svg+xml,", rdns: "com.example.wallet" }; window.dispatchevent( new customevent("eip6963:announceprovider", { detail: object.freeze({ info, provider }), }) ); } window.addeventlistener( "eip6963:requestprovider", (event: eip6963requestproviderevent) => { announceprovider(); } ); announceprovider(); } dapp implementation here is a reference implementation for a dapp to display and track multiple wallet providers that are injected by browser extensions. const providers: eip6963providerdetail[]; function onpageload() { window.addeventlistener( "eip6963:announceprovider", (event: eip6963announceproviderevent) => { providers.push(event.detail); } ); window.dispatchevent(new event("eip6963:requestprovider")); } security considerations eip-1193 security considerations the security considerations of eip-1193 apply to this eip. implementers are expected to consider and follow the guidance of the providers they’re utilizing as well. prototype pollution of wallet provider objects browser extensions, and therefore wallet extensions, are able to modify the contents of the page and the provider object by design. the provider objects of various wallets are considered a highly trusted interface to communicate transaction data. in order to prevent the page or various other extensions from modifying the interaction between the dapp and the wallet in an unexpected way, the best practice is to “freeze” the provider discovery object by utilizing object.freeze() on the eip1193provider object before the wallet dispatches it in the eip6963:announceprovider event. however, there are difficulties that can occur around web compatability where pages need to monkey patch the object. in scenarios like this there’s a tradeoff that needs to be made between security and web compatibility that wallet implementers are expected to consider. wallet imitation and manipulation similarly so, dapps are expected to actively detect for misbehavior of properties or functions being modified in order to tamper with or modify other wallets. one way this can be easily achieved is to look for when the uuid property within two eip6963providerinfo objects match. dapps and dapp discovery libraries are expected to consider other potential methods that the eip6963providerinfo objects are being tampered with and consider additional mitigation techniques to prevent this as well in order to protect the user. prevent svg javascript execution the use of svg images introduces a cross-site scripting risk as they can include javascript code. this javascript executes within the context of the page and can therefore modify the page or the contents of the page. so when considering the experience of rendering the icons, dapps need to take into consideration how they’ll approach handling these concerns in order to prevent an image being used as an obfuscation technique to hide malicious modifications to the page or to other wallets. prevent wallet fingerprinting one advantage to the concurrency event loop utilized by this design is that it operates in a manner where either the dapp or the wallet can initiate the flow to announce a provider. for this reason, wallet implementers can now consider whether or not they wish to announce themselves to all pages or attempt alternative means in order to reduce the ability for a user to be fingerprinted by the injection of the window.ethereum object. some examples, of alternative flows to consider would be to wait to inject the provider object until the dapp has announced the eip6963:requestprovider. at that point, the wallet can initiate a ui consent flow to ask the user if they would like to share their wallet address. this allows for the wallet to enable the option of a “private connect” feature. however, if this approach is taken, wallets must also consider how they intend to support backwards compatibility with a dapp that does not support this eip. copyright copyright and related rights waived via cc0. citation please cite this document as: pedro gomes (@pedrouid), kosala hemachandra (@kvhnuke), richard moore (@ricmoo), gregory markou (@gregthegreek), kyle den hartog (@kdenhartog), glitch (@glitch-txs), jake moxey (@jxom), pierre bertet (@bpierre), darryl yeo (@darrylyeo), yaroslav sergievsky (@everdimension), "eip-6963: multi injected provider discovery," ethereum improvement proposals, no. 6963, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6963. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. proof of stake: how i learned to love weak subjectivity | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search proof of stake: how i learned to love weak subjectivity posted by vitalik buterin on november 25, 2014 research & development proof of stake continues to be one of the most controversial discussions in the cryptocurrency space. although the idea has many undeniable benefits, including efficiency, a larger security margin and future-proof immunity to hardware centralization concerns, proof of stake algorithms tend to be substantially more complex than proof of work-based alternatives, and there is a large amount of skepticism that proof of stake can work at all, particularly with regard to the supposedly fundamental "nothing at stake" problem. as it turns out, however, the problems are solvable, and one can make a rigorous argument that proof of stake, with all its benefits, can be made to be successful but at a moderate cost. the purpose of this post will be to explain exactly what this cost is, and how its impact can be minimized. economic sets and nothing at stake first, an introduction. the purpose of a consensus algorithm, in general, is to allow for the secure updating of a state according to some specific state transition rules, where the right to perform the state transitions is distributed among some economic set. an economic set is a set of users which can be given the right to collectively perform transitions via some algorithm, and the important property that the economic set used for consensus needs to have is that it must be securely decentralized meaning that no single actor, or colluding set of actors, can take up the majority of the set, even if the actor has a fairly large amount of capital and financial incentive. so far, we know of three securely decentralized economic sets, and each economic set corresponds to a set of consensus algorithms: owners of computing power: standard proof of work, or tapow. note that this comes in specialized hardware, and (hopefully) general-purpose hardware variants. stakeholders: all of the many variants of proof of stake a user's social network: ripple/stellar-style consensus note that there have been some recent attempts to develop consensus algorithms based on traditional byzantine fault tolerance theory; however, all such approaches are based on an m-of-n security model, and the concept of "byzantine fault tolerance" by itself still leaves open the question of which set the n should be sampled from. in most cases, the set used is stakeholders, so we will treat such neo-bft paradigms are simply being clever subcategories of "proof of stake". proof of work has a nice property that makes it much simpler to design effective algorithms for it: participation in the economic set requires the consumption of a resource external to the system. this means that, when contributing one's work to the blockchain, a miner must make the choice of which of all possible forks to contribute to (or whether to try to start a new fork), and the different options are mutually exclusive. double-voting, including double-voting where the second vote is made many years after the first, is unprofitablem since it requires you to split your mining power among the different votes; the dominant strategy is always to put your mining power exclusively on the fork that you think is most likely to win. with proof of stake, however, the situation is different. although inclusion into the economic set may be costly (although as we will see it not always is), voting is free. this means that "naive proof of stake" algorithms, which simply try to copy proof of work by making every coin a "simulated mining rig" with a certain chance per second of making the account that owns it usable for signing a block, have a fatal flaw: if there are multiple forks, the optimal strategy is to vote on all forks at once. this is the core of "nothing at stake". note that there is one argument for why it might not make sense for a user to vote on one fork in a proof-of-stake environment: "altruism-prime". altruism-prime is essentially the combination of actual altruism (on the part of users or software developers), expressed both as a direct concern for the welfare of others and the network and a psychological moral disincentive against doing something that is obviously evil (double-voting), as well as the "fake altruism" that occurs because holders of coins have a desire not to see the value of their coins go down. unfortunately, altruism-prime cannot be relied on exclusively, because the value of coins arising from protocol integrity is a public good and will thus be undersupplied (eg. if there are 1000 stakeholders, and each of their activity has a 1% chance of being "pivotal" in contributing to a successful attack that will knock coin value down to zero, then each stakeholder will accept a bribe equal to only 1% of their holdings). in the case of a distribution equivalent to the ethereum genesis block, depending on how you estimate the probability of each user being pivotal, the required quantity of bribes would be equal to somewhere between 0.3% and 8.6% of total stake (or even less if an attack is nonfatal to the currency). however, altruism-prime is still an important concept that algorithm designers should keep in mind, so as to take maximal advantage of in case it works well. short and long range if we focus our attention specifically on short-range forks forks lasting less than some number of blocks, perhaps 3000, then there actually is a solution to the nothing at stake problem: security deposits. in order to be eligible to receive a reward for voting on a block, the user must put down a security deposit, and if the user is caught either voting on multiple forks then a proof of that transaction can be put into the original chain, taking the reward away. hence, voting for only a single fork once again becomes the dominant strategy. another set of strategies, called "slasher 2.0" (in contrast to slasher 1.0, the original security deposit-based proof of stake algorithm), involves simply penalizing voters that vote on the wrong fork, not voters that double-vote. this makes analysis substantially simpler, as it removes the need to pre-select voters many blocks in advance to prevent probabilistic double-voting strategies, although it does have the cost that users may be unwilling to sign anything if there are two alternatives of a block at a given height. if we want to give users the option to sign in such circumstances, a variant of logarithmic scoring rules can be used (see here for more detailed investigation). for the purposes of this discussion, slasher 1.0 and slasher 2.0 have identical properties. the reason why this only works for short-range forks is simple: the user has to have the right to withdraw the security deposit eventually, and once the deposit is withdrawn there is no longer any incentive not to vote on a long-range fork starting far back in time using those coins. one class of strategies that attempt to deal with this is making the deposit permanent, but these approaches have a problem of their own: unless the value of a coin constantly grows so as to continually admit new signers, the consensus set ends up ossifying into a sort of permanent nobility. given that one of the main ideological grievances that has led to cryptocurrency's popularity is precisely the fact that centralization tends to ossify into nobilities that retain permanent power, copying such a property will likely be unacceptable to most users, at least for blockchains that are meant to be permanent. a nobility model may well be precisely the correct approach for special-purpose ephemeral blockchains that are meant to die quickly (eg. one might imagine such a blockchain existing for a round of a blockchain-based game). one class of approaches at solving the problem is to combine the slasher mechanism described above for short-range forks with a backup, transactions-as-proof-of-stake, for long range forks. tapos essentially works by counting transaction fees as part of a block's "score" (and requiring every transaction to include some bytes of a recent block hash to make transactions not trivially transferable), the theory being that a successful attack fork must spend a large quantity of fees catching up. however, this hybrid approach has a fundamental flaw: if we assume that the probability of an attack succeeding is near-zero, then every signer has an incentive to offer a service of re-signing all of their transactions onto a new blockchain in exchange for a small fee; hence, a zero probability of attacks succeeding is not game-theoretically stable. does every user setting up their own node.js webapp to accept bribes sound unrealistic? well, if so, there's a much easier way of doing it: sell old, no-longer-used, private keys on the black market. even without black markets, a proof of stake system would forever be under the threat of the individuals that originally participated in the pre-sale and had a share of genesis block issuance eventually finding each other and coming together to launch a fork. because of all the arguments above, we can safely conclude that this threat of an attacker building up a fork from arbitrarily long range is unfortunately fundamental, and in all non-degenerate implementations the issue is fatal to a proof of stake algorithm's success in the proof of work security model. however, we can get around this fundamental barrier with a slight, but nevertheless fundamental, change in the security model. weak subjectivity although there are many ways to categorize consensus algorithms, the division that we will focus on for the rest of this discussion is the following. first, we will provide the two most common paradigms today: objective: a new node coming onto the network with no knowledge except (i) the protocol definition and (ii) the set of all blocks and other "important" messages that have been published can independently come to the exact same conclusion as the rest of the network on the current state. subjective: the system has stable states where different nodes come to different conclusions, and a large amount of social information (ie. reputation) is required in order to participate. systems that use social networks as their consensus set (eg. ripple) are all necessarily subjective; a new node that knows nothing but the protocol and the data can be convinced by an attacker that their 100000 nodes are trustworthy, and without reputation there is no way to deal with that attack. proof of work, on the other hand, is objective: the current state is always the state that contains the highest expected amount of proof of work. now, for proof of stake, we will add a third paradigm: weakly subjective: a new node coming onto the network with no knowledge except (i) the protocol definition, (ii) the set of all blocks and other "important" messages that have been published and (iii) a state from less than n blocks ago that is known to be valid can independently come to the exact same conclusion as the rest of the network on the current state, unless there is an attacker that permanently has more than x percent control over the consensus set. under this model, we can clearly see how proof of stake works perfectly fine: we simply forbid nodes from reverting more than n blocks, and set n to be the security deposit length. that is to say, if state s has been valid and has become an ancestor of at least n valid states, then from that point on no state s' which is not a descendant of s can be valid. long-range attacks are no longer a problem, for the trivial reason that we have simply said that long-range forks are invalid as part of the protocol definition. this rule clearly is weakly subjective, with the added bonus that x = 100% (ie. no attack can cause permanent disruption unless it lasts more than n blocks). another weakly subjective scoring method is exponential subjective scoring, defined as follows: every state s maintains a "score" and a "gravity" score(genesis) = 0, gravity(genesis) = 1 score(block) = score(block.parent) + weight(block) * gravity(block.parent), where weight(block) is usually 1, though more advanced weight functions can also be used (eg. in bitcoin, weight(block) = block.difficulty can work well) if a node sees a new block b' with b as parent, then if n is the length of the longest chain of descendants from b at that time, gravity(b') = gravity(b) * 0.99 ^ n (note that values other than 0.99 can also be used). essentially, we explicitly penalize forks that come later. ess has the property that, unlike more naive approaches at subjectivity, it mostly avoids permanent network splits; if the time between the first node on the network hearing about block b and the last node on the network hearing about block b is an interval of k blocks, then a fork is unsustainable unless the lengths of the two forks remain forever within roughly k percent of each other (if that is the case, then the differing gravities of the forks will ensure that half of the network will forever see one fork as higher-scoring and the other half will support the other fork). hence, ess is weakly subjective with x roughly corresponding to how close to a 50/50 network split the attacker can create (eg. if the attacker can create a 70/30 split, then x = 0.29). in general, the "max revert n blocks" rule is superior and less complex, but ess may prove to make more sense in situations where users are fine with high degrees of subjectivity (ie. n being small) in exchange for a rapid ascent to very high degrees of security (ie. immune to a 99% attack after n blocks). consequences so what would a world powered by weakly subjective consensus look like? first of all, nodes that are always online would be fine; in those cases weak subjectivity is by definition equivalent to objectivity. nodes that pop online once in a while, or at least once every n blocks, would also be fine, because they would be able to constantly get an updated state of the network. however, new nodes joining the network, and nodes that appear online after a very long time, would not have the consensus algorithm reliably protecting them. fortunately, for them, the solution is simple: the first time they sign up, and every time they stay offline for a very very long time, they need only get a recent block hash from a friend, a blockchain explorer, or simply their software provider, and paste it into their blockchain client as a "checkpoint". they will then be able to securely update their view of the current state from there. this security assumption, the idea of "getting a block hash from a friend", may seem unrigorous to many; bitcoin developers often make the point that if the solution to long-range attacks is some alternative deciding mechanism x, then the security of the blockchain ultimately depends on x, and so the algorithm is in reality no more secure than using x directly implying that most x, including our social-consensus-driven approach, are insecure. however, this logic ignores why consensus algorithms exist in the first place. consensus is a social process, and human beings are fairly good at engaging in consensus on our own without any help from algorithms; perhaps the best example is the rai stones, where a tribe in yap essentially maintained a blockchain recording changes to the ownership of stones (used as a bitcoin-like zero-intrinsic-value asset) as part of its collective memory. the reason why consensus algorithms are needed is, quite simply, because humans do not have infinite computational power, and prefer to rely on software agents to maintain consensus for us. software agents are very smart, in the sense that they can maintain consensus on extremely large states with extremely complex rulesets with perfect precision, but they are also very ignorant, in the sense that they have very little social information, and the challenge of consensus algorithms is that of creating an algorithm that requires as little input of social information as possible. weak subjectivity is exactly the correct solution. it solves the long-range problems with proof of stake by relying on human-driven social information, but leaves to a consensus algorithm the role of increasing the speed of consensus from many weeks to twelve seconds and of allowing the use of highly complex rulesets and a large state. the role of human-driven consensus is relegated to maintaining consensus on block hashes over long periods of time, something which people are perfectly good at. a hypothetical oppressive government which is powerful enough to actually cause confusion over the true value of a block hash from one year ago would also be powerful enough to overpower any proof of work algorithm, or cause confusion about the rules of blockchain protocol. note that we do not need to fix n; theoretically, we can come up with an algorithm that allows users to keep their deposits locked down for longer than n blocks, and users can then take advantage of those deposits to get a much more fine-grained reading of their security level. for example, if a user has not logged in since t blocks ago, and 23% of deposits have term length greater than t, then the user can come up with their own subjective scoring function that ignores signatures with newer deposits, and thereby be secure against attacks with up to 11.5% of total stake. an increasing interest rate curve can be used to incentivize longer-term deposits over shorter ones, or for simplicity we can just rely on altruism-prime. marginal cost: the other objection one objection to long-term deposits is that it incentivizes users to keep their capital locked up, which is inefficient, the exact same problem as proof of work. however, there are four counterpoints to this. first, marginal cost is not total cost, and the ratio of total cost divided by marginal cost is much less for proof of stake than proof of work. a user will likely experience close to no pain from locking up 50% of their capital for a few months, a slight amount of pain from locking up 70%, but would find locking up more than 85% intolerable without a large reward. additionally, different users have very different preferences for how willing they are to lock up capital. because of these two factors put together, regardless of what the equilibrium interest rate ends up being, the vast majority of the capital will be locked up at far below marginal cost. second, locking up capital is a private cost, but also a public good. the presence of locked up capital means that there is less money supply available for transactional purposes, and so the value of the currency will increase, redistributing the capital to everyone else, creating a social benefit. third, security deposits are a very safe store of value, so (i) they substitute the use of money as a personal crisis insurance tool, and (ii) many users will be able to take out loans in the same currency collateralized by the security deposit. finally, because proof of stake can actually take away deposits for misbehaving, and not just rewards, it is capable of achieving a level of security much higher than the level of rewards, whereas in the case of proof of work the level of security can only equal the level of rewards. there is no way for a proof of work protocol to destroy misbehaving miners' asics. fortunately, there is a way to test those assumptions: launch a proof of stake coin with a stake reward of 1%, 2%, 3%, etc per year, and see just how large a percentage of coins become deposits in each case. users will not act against their own interests, so we can simply use the quantity of funds spent on consensus as a proxy for how much inefficiency the consensus algorithm introduces; if proof of stake has a reasonable level of security at a much lower reward level than proof of work, then we know that proof of stake is a more efficient consensus mechanism, and we can use the levels of participation at different reward levels to get an accurate idea of the ratio between total cost and marginal cost. ultimately, it may take years to get an exact idea of just how large the capital lockup costs are. altogether, we now know for certain that (i) proof of stake algorithms can be made secure, and weak subjectivity is both sufficient and necessary as a fundamental change in the security model to sidestep nothing-at-stake concerns to accomplish this goal, and (ii) there are substantial economic reasons to believe that proof of stake actually is much more economically efficient than proof of work. proof of stake is not an unknown; the past six months of formalization and research have determined exactly where the strengths and weaknesses lie, at least to as large extent as with proof of work, where mining centralization uncertainties may well forever abound. now, it's simply a matter of standardizing the algorithms, and giving blockchain developers the choice. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements security alert – [previous security patch can lead to invalid state root on go clients with a specific transaction sequence – fixed. please update.] | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search security alert – [previous security patch can lead to invalid state root on go clients with a specific transaction sequence – fixed. please update.] posted by jutta steiner on september 10, 2015 security summary: implementation bug in the go client may lead to invalid state affected client versions: latest (unpatched) versions of go client; v1.1.2, v1.0.4 tags and develop, master branches before september 9. likelihood: low severity: high impact: high details: go ethereum client does not correctly restore state of execution environment when a transaction goes out-of-gas if within the same block a contract was suicided. this would result in an invalid copy operation of the state object; flagging the contract as not deleted. this operation would cause a consensus issue between the other implementations. effects on expected chain reorganisation depth: none remedial action taken by ethereum: provision of hotfixes as below. proposed temporary workaround: use python or c++ client if using the ppa: sudo apt-get update then sudo apt-get upgrade if using brew: brew update then brew reinstall ethereum if using a windows binary: download the updated binary from https://github.com/ethereum/go-ethereum/releases/tag/v1.1.3 master branch commit: https://github.com/ethereum/go-ethereum/commit/9ebe787d3afe35902a639bf7c1fd68d1e591622a if you’re building from source: git fetch origin && git checkout origin/master followed by a make geth previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-2593: escalator fee market change for eth 1.0 chain ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-2593: escalator fee market change for eth 1.0 chain authors dan finlay created 2020-03-13 discussion link https://ethresear.ch/t/another-simple-gas-fee-model-the-escalator-algorithm-from-the-agoric-papers/6399 table of contents simple summary abstract motivation user strategies under various conditions and algorithms user results under various conditions and algorithms specification backwards compatibility test cases implementation security considerations copyright simple summary the current “first price auction” fee model in ethereum is inefficient and needlessly costly to users. this eip proposes a way to replace this with a mechanism that allows dynamically priced transaction fees and efficient transaction price discovery. abstract based on the agoric papers. each transaction would have the option of providing parameters that specify an “escalating” bid, creating a time-based auction for validators to include that transaction. this creates highly efficient price discovery, where the price will always immediately fall to the highest bid price, which is not necessarily that user’s highest price they would pay. motivation ethereum currently prices transaction fees using a simple first-price auction, which leads to well documented inefficiencies (some of which are documented in eip-1559) when users are trying to estimate what price will get a transaction included in a block, especially during times of price volatility and full blocks. eip 1559 is currently being championed as an improvement for the ethereum protocol, and while i agree that the gas market is very inefficient, since a change like this will affect all client and wallet implementations, the ethereum community should make sure to make a selection based on solid reasoning and justifications, which i believe 1559 is currently lacking. to facilitate a more productive and concrete discussion about the gas fee market, i felt it was important to present an alternative that is clearly superior to the status quo, so that any claimed properties of eip-1559 can be compared to a plausible alternative improvement. i suggest the three gas payment algorithms be compared under all combinations of these conditions: blocks that are regularly half full, blocks that are regularly less than half full, and blocks that repeatedly full in a surprising (“black swan”) series. users that are willing to wait for a price that may be below the market rate, vs users who value inclusion urgently and are willing to pay above market rate. we should then ask: is the user willing to pay the most in a given scenario also likely to have their transaction processed in a time period they find acceptable? are users who want a good price likely to get included in a reasonable period of time? (ideally within one block) i believe that under this analysis we will find that the escalator algorithm outperforms eip-1559 in both normal and volatile conditions, for both high-stakes transactions and more casual users looking for a good price. while i think a deeper simulation/analysis should be completed, i will share my expected results under these conditions. furthermore, by introducing tx fee payment related to the current time, we create an incentive for miners to more honestly report the current time. user strategies under various conditions and algorithms first i will suggest a likely optimal strategy for different players under the conditions of the different algorithms being considered. gas strategy current single-price eip 1559 escalator blocks regularly half full, user wants urgent inclusion. user bids within the range of prices that have been recently accepted, likely over-pays slightly. user bids one price tier over the current rate, and is likely included. user bids a range from the low end of recently included to the high end, and is likely included at the lowest rate possible. blocks regularly half full, user willing to wait for a good price. user bids below or near the low end of the recently accepted prices, may need to wait for a while. if waiting too long, user may need to re-submit with a higher price. user bids under or at the current price tier, and may wait for the price to fall. if waiting too long, user may need to re-submit with a higher price. user bids as low as they’d like, but set an upper bound on how long they’re willing to wait before increasing price. blocks regularly full, user wants urgent inclusion. user bids over the price of all recently accepted transactions, almost definitely over-paying significantly. user bids over the current price tier, and needs to increase their tip parameter to be competitive on the next block, recreating the single-price auction price problem. user bids over a price that has been accepted consistently, with an escalating price in case that price is not high enough. blocks regularly full, user willing to wait for a good price. user bids below the low end of the recently accepted prices, may need to wait for a while. if waiting too long, user may need to re-submit with a higher price. user bids under or at the current price tier, and may wait for the price to fall. if waiting too long, user may need to re-submit with a higher price. user bids as low as they’d like, but set an upper bound on how long they’re willing to wait before increasing price. blocks regularly under-full, user wants urgent inclusion. user bids within or over the range of prices that have been recently accepted, likely over-pays slightly, and is likely included in the next block. user bids at or over the current price tier, and is likely included in the next block. user submits bid starting within recently accepted prices, is likely accepted in the next block. blocks regularly under-full, user willing to wait for a good price. user bids below the low end of the recently accepted prices, may need to wait for a while. if waiting too long, user may need to re-submit with a higher price. user bids at or under the current price tier, and is likely included in the next block. if bidding under and waiting too long, user may need to re-submit with a higher price. user bids as low as they’d like, but set an upper bound on how long they’re willing to wait before increasing price, is likely included in the next few blocks at the lowest possible price. user results under various conditions and algorithms now i will consider the ultimate results of the strategies listed above. are users happy under these conditions? did we save users money? were users who wanted urgent inclusion able to secure it? gas strategy current single-price eip 1559 escalator blocks regularly half full, user wants urgent inclusion. user pays an expected amount, and gets transaction mined reliably. user pays an expected amount, and gets transaction mined reliably. user pays an expected amount, and gets transaction mined reliably. blocks regularly half full, user willing to wait for a good price. user can wait for a better price, but may need to resubmit re-signed transactions. user can wait for a better price, but may need to resubmit re-signed transactions. user can discover the lowest price within their time preference with a single signature. blocks regularly full, user wants urgent inclusion. user over-pays, but reliably gets transaction included. due to tip parameter “breaking tie” within a block, user over-pays for reliable inclusion. user is able to balance the amount of overpayment they risk with the urgency they require. blocks regularly full, user willing to wait for a good price. user chooses their price, and waits for it, or manually re-submits. user chooses their price, and waits for it, or manually re-submits. user chooses their lowest price, but also their highest price and maximum wait time, so no resubmission is needed. blocks regularly under-full, user wants urgent inclusion. user over-pays, but reliably gets transaction included. user bids at or over current price tier, gets transaction mined reliably. user pays an expected amount, and gets transaction mined reliably. blocks regularly under-full, user willing to wait for a good price. user bids below the low end of the recently accepted prices, may need to wait for a while. if waiting too long, user may need to re-submit with a higher price. user chooses their price, and waits for it, or manually re-submits. user chooses their lowest price, but also their highest price and maximum wait time, so no resubmission is needed. in all cases, the escalator algorithm as i have described is able to perform optimally. the current gas auction model works well under half-full and less conditions, but for users with urgent needs, has the downside of overpayment. for users seeking a low price, the current model has the downside of requiring re-submission, but has the benefit of always giving users a path towards reliable block inclusion. eip-1559 also performs well under normal conditions, but under conditions where blocks are regularly full, the price discovery mechanism breaks, and miners will fall back to the tip parameter to choose the transactions to include, meaning that under network congestion, eip-1559 forces users to either choose efficient prices or certainty of next-block inclusion. eip-1559 also has all the re-submission issues of the current model in situations where a user would like to pay under the current market rate, but has certain time constraints limiting their patience. the escalator algorithm is the only strategy listed here that allows users to discover the lowest possible price given the network conditions and their time constraints. specification client-wide parameters initial_fork_blknum: tbd transaction parameters the transaction gasprice parameter is now optional, and if excluded can be replaced by these parameters instead: start_price: the lowest price that the user would like to pay for the transaction. start_time: the first time that this transaction is valid at. max_price: the maximum price the sender would be willing to pay to have this transaction processed. max_time: the time at which point the user’s max_price is achieved. the transaction remains valid after this time at that price. proposal for all blocks where block.number >= initial_fork_blknum: when processing a transaction with the new pricing parameters, miners now receive a fee based off of the following linear function, where block is the current block number: if block > max_time then tx_fee = max_price. tx_fee = start_price + ((max_price start_price) / (max_time start_time) * (block start_time)) as a javascript function: function txfee (starttime, startprice, maxtime, maxprice, currenttime) { if (currenttime >= maxtime) return maxprice const pricerange = maxprice startprice const blockrange = maxtime starttime const slope = pricerange / blockrange return startprice + (slope * (currenttime starttime)) } backwards compatibility since a current gasprice transaction is effectively a flat-escalated transaction bid, it is entirely compatible with this model, and so there is no concrete requirement to deprecate current transaction processing logic, allowing cold wallets and hardware wallets to continue working for the foreseeable future. test cases tbd implementation tbd security considerations the security considerations for this eip are: none currently known. copyright copyright and related rights waived via cc0. citation please cite this document as: dan finlay , "eip-2593: escalator fee market change for eth 1.0 chain [draft]," ethereum improvement proposals, no. 2593, march 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2593. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1706: disable sstore with gasleft lower than call stipend ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-1706: disable sstore with gasleft lower than call stipend authors alex forshtat , yoav weiss created 2019-01-15 discussion link https://github.com/alex-forshtat-tbk/eips/issues/1 requires eip-1283 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary the proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. this proposal will make the old assumptions hold even after a network upgrade. abstract eip-1283 significantly lowers the gas costs of writing to contract’s storage. this created a danger of a new kind of reentrancy attacks on existing contracts as solidity by default grants a ‘stipend’ of 2300 gas to simple transfer calls. this danger is easily mitigated if sstore is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of this eip. motivation an attack that is described in this article. explicitly specifying the call stipend as an invariant will have a positive effect on ethereum protocol security: https://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_constantinople/ee5uvjt specification add the following condition to to the sstore opcode gas cost calculation: if gasleft is less than or equal to 2300, fail the current call frame with ‘out of gas’ exception. rationale in order to keep in place the implicit reentrancy protection of existing contracts, transactions should not be allowed to modify state if the remaining gas is lower then the 2300 stipend given to ‘transfer’/’send’ in solidity. these are other proposed remediations and objections to implementing them: drop eip-1283 and abstain from modifying sstore cost eip-1283 is an important update it was accepted and implemented on test networks and in clients. add a new call context that permits log opcodes but not changes to state. adds another call type beyond existing regular/staticcall raise the cost of sstore to dirty slots to >=2300 gas makes net gas metering much less useful. reduce the gas stipend makes the stipend almost useless. increase the cost of writes to dirty slots back to 5000 gas, but add 4800 gas to the refund counter still doesn’t make the invariant explicit. requires callers to supply more gas, just to have it refunded add contract metadata specifying per-contract evm version, and only apply sstore changes to contracts deployed with the new version. backwards compatibility performing sstore has never been possible with less than 5000 gas, so it does not introduce incompatibility to the ethereum mainnet. gas estimation should account for this requirement. test cases test cases for an implementation are mandatory for eips that are affecting consensus changes. other eips can choose to include links to test cases if applicable. todo implementation todo copyright copyright and related rights waived via cc0. citation please cite this document as: alex forshtat , yoav weiss , "eip-1706: disable sstore with gasleft lower than call stipend [draft]," ethereum improvement proposals, no. 1706, january 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1706. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6190: verkle-compatible selfdestruct ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-6190: verkle-compatible selfdestruct changes selfdestruct to only cause a finite number of state changes authors gavin john (@pandapip1) created 2022-12-20 discussion link https://ethereum-magicians.org/t/eip-6190-functional-selfdestruct/12232 requires eip-2929, eip-6188, eip-6189 table of contents abstract motivation specification prerequisites selfdestruct behaviour gas cost of selfdestruct rationale backwards compatibility security considerations copyright abstract changes selfdestruct to only cause a finite number of state changes. motivation the selfdestruct instruction has a fixed price, but is unbounded in storage/account changes (it needs to delete all keys). this has been an outstanding concern for some time. furthermore, with verkle trees accounts will be organised differently. account properties, including storage, would have individual keys. it would not be possible to traverse and find all used keys. this makes selfdestruct very challenging to support in verkle trees. this eip is a step towards supporting selfdestruct in verkle trees. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119 and rfc 8174. prerequisites eip-6188 and eip-6189 must be used for this eip to function correctly. selfdestruct behaviour instead of destroying the contract at the end of the transaction, instead, the following will occur at the end of the transaction in which it is invoked: the contract’s code is set to 0x1, and its nonce is set to 2^64-1. the contract’s 0th storage slot is set to the address that would be issued if the contract used the create opcode (keccak256(contractaddress, nonce)). note that the nonce is always 2^64-1. if the contract was self-destructed after the call being forwarded by one or more alias contracts, the alias contract’s 0th storage slot is set to the address calculated in step 2. the contract’s balance is transferred, in its entirety, to the address on the top of the stack. the top of the stack is popped. gas cost of selfdestruct the base gas cost of selfdestruct is set to 5000. the gas cost of selfdestruct is increased by 5000 for each alias contract that forwarded to the contract being self-destructed. finally, the eip-2929 gas cost increase is applied. rationale this eip is designed to be a step towards supporting selfdestruct in verkle trees while making the minimum amount of changes. the 5000 base gas cost and additional alias contracts represents the cost of setting the account nonce and first storage slot. the eip-2929 gas cost increase is preserved for the reasons mentioned in said eip’s rationale. the nonce of 2^64-1 was chosen since it is the nonce protected by eip-6188. the account code of 0x1 was chosen since it was the code specified in eip-6189. the address being the same as the one created by create is designed to reduce possible attack vectors by not introducing a new mechanism by which accounts can be created at specific addresses. backwards compatibility this eip requires a protocol upgrade, since it modifies consensus rules. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: gavin john (@pandapip1), "eip-6190: verkle-compatible selfdestruct [draft]," ethereum improvement proposals, no. 6190, december 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6190. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6475: ssz optional ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: core eip-6475: ssz optional new ssz type to represent optional values authors etan kissling (@etan-status), zahary karadjov (@zah) created 2023-02-09 discussion link https://ethereum-magicians.org/t/eip-6475-ssz-optional/12891 table of contents abstract motivation specification type definition default value serialization deserialization merkleization rationale why not union[none, t]? why not list[t, 1]? backwards compatibility test cases reference implementation security considerations copyright abstract this eip introduces a new simple serialize (ssz) type to represent optional[t] values. motivation optional values are currently only representable in ssz using workarounds. adding proper support provides these benefits: better readability: ssz structures with optional values can be represented with idiomatic types of the underlying programming language, e.g., optional[t] in python, making them easier to interact with. compact serialization: ssz serialization can rely on the binary nature of optional values; they either exist or they don’t. this allows more compact serialization than using alternative approaches based on workarounds. 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. type definition optional[t] is defined as a type that can represent: a value of ssz type t absence of a value, indicated by none default value the default value of optional[t] is none. serialization if value is none: return b"" else: return b"\x01" + serialize(value) deserialization the deserialization of an optional[t] depends on the input length: if the input length is 0, the value is none. otherwise, the first byte of the deserialization scope must be checked to be 0x01, the remainder of the scope is deserialized same as t. merkleization an optional[t] is merkleized as a list[t, 1]. if the value is none, the list length is 0. otherwise, the list length is 1, and the first list element contains the underlying value. rationale why not union[none, t]? union[none, t] leaves ambiguity about the intention whether the type may be extended in the future, i.e., union[none, t, u]. furthermore, ssz union types are currently not used in any final ethereum specification and do not have a finalized design themselves. if the only use case is a workaround for lack of optional[t], the simpler optional[t] type is sufficient, and support for general unions could be delayed until really needed. note that the design of optional[t] could be used as basis for a more general union. why not list[t, 1]? the serialization is less compact for variable-length t, due to the extra offset table at the beginning of the list to indicate the list length. backwards compatibility union[none, t] and list[t, 1] workarounds are not used at this time to represent optional[t]. test cases see eip assets. reference implementation python: see eip assets, based on protolambda/remerkleable nim: status-im/nim-ssz-serialization security considerations none copyright copyright and related rights waived via cc0. citation please cite this document as: etan kissling (@etan-status), zahary karadjov (@zah), "eip-6475: ssz optional [draft]," ethereum improvement proposals, no. 6475, february 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6475. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. the ethereum development process | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search the ethereum development process posted by gavin wood on march 5, 2015 research & development so i'm not sure if this kind of development methodology has ever been applied to such an extreme before so i figured i'd document it. in a nutshell, it's sort of like test-driven triplet-programming development. while speed-developing our alpha codebase, four of us sat around a table in the office in berlin. three people (vitalik, jeff and me) each coders of their own clean-room implementation of the ethereum protocol. the fourth was christoph, our master of testing. our target was to have three fully compatible implementations as well as an unambiguous specification by the end of three days of substantial development. over distance, this process normally takes a few weeks. this time we needed to expedite it; our process was quite simple. first we discuss the various consensus-breaking changes and formally describe them as best we can. then, individually we each crack on coding up the changes simultaneously, popping our heads up about possible clarifications to the specifications as needed. meanwhile, christoph devises and codes tests, populating the results either manually or with the farthest-ahead of the implementations (c++, generally :-p). after a milestone's worth of changes are coded up and the tests written, each clean-room implementation is tested against the common test data that christoph compiled. where issues are found, we debug in a group. so far, this has proved to be an effective way of producing well-tested code quickly, and perhaps more importantly, in delivering clear unambiguous formal specifications. are there any more examples of such techniques taken to the extreme? previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-1129: standardised dapp announcements ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1129: standardised dapp announcements authors jan turk (@thunderdeliverer) created 2018-05-31 discussion link https://ethereum-magicians.org/t/eip-sda-standardised-dapp-announcements/508?u=thunderdeliverer table of contents simple summary abstract motivation specification structures methods events rationale test cases implementation copyright simple summary standardisation of announcements in dapps and services on ethereum network. this erc provides proposed mechanics to increase the quality of service provided by dapp developers and service providers, by setting a framework for announcements. be it transitioning to a new smart contract or just freezing the service for some reason. abstract the proposed erc defines format on how to post announcements about the service as well as how to remove them. it also defines mechanics on posting permissions and human friendly interface. motivation currently there are no guidelines on how to notify the users of the service status in the dapps. this is especially obvious in erc20 and it’s derivates. if the service is impeded by any reason it is good practice to have some sort of guidelines on how to announce that to the user. the standardisation would also provide traceability of the service’s status. specification structures announcer stores information about the announcement maker. the allowedtopost stores posting permissions and is used for modifiers limiting announcement posting only to authorised entities. the name is used for human friendly identifier of the author to be stored. struct announcer{ bool allowedtopost; string name; } announcement stores information about the individual announcement. the human friendly author identifier is stored in author. ethereum address associated with the author is stored in authoraddress. the announcement itself is stored in post. struct announcement{ string author; address authoraddress; string post; } methods the number of ammouncements returns the number of announcement currently active. optional this method can be used to provide quicker information for the ui, but could also be retrieved from numberofmessages variable. function thenumberofannouncements() public constant returns(uint256 _numberofannouncements) read posts returns the specified announcement as well as human friendly poster identificator (name or nickname). function readposts(uint256 _postnumber) public constant returns(string _author, string _post) give posting permission sets posting permissions of the address _newannouncer to _postingprivileges and can also be used to revoke those permissions. the _postername is human friendly author identificator used in the announcement data. function givepostingpermission(address _newannouncer, bool _postingprivileges, string _postername) public onlyowner returns(bool success) can post checks if the entity that wants to post an announcement has the posting privilieges. modifier canpost{ require(posterdata[msg.sender].allowedtopost); _; } post announcement lets user post announcements, but only if they have their posting privileges set to true. the announcement is sent in _message variable. function postannouncement(string _message) public canpost remove announcement removes an announcement with _messagenumber announcement identifier and rearranges the mapping so there are no empty slots. the _removalreason is used to update users if the issue that caused the announcement is resolved or what are the next steps from the service provider / dapp development team. function removeannouncement(uint256 _messagenumber, string _removalreason) public events new announcement must trigger when new announcement is created. every time there is a new announcement it should be advertised in this event. it holds the information about author author and the announcement istelf message. event newannouncement(string author, string message) removed announcement must trigger when an announcement is removed. every time an announcement is removed it should be advertised in this event. it holds the information about author author, the announcement itself message, the reason for removal or explanation of the solution reason and the address of the entity that removed the announcement remover. event removedannouncement(string author, string message, string reason, address remover); rationale the proposed solution was designed with ux in mind . it provides mechanics that serve to present the announcements in the user friendly way. it is meant to be deployed as a solidity smart contract on ethereum network. test cases the proposed version is deployed on ropsten testnet all of the information can be found here. implementation copyright copyright and related rights waived via cc0. citation please cite this document as: jan turk (@thunderdeliverer), "erc-1129: standardised dapp announcements [draft]," ethereum improvement proposals, no. 1129, may 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1129. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. state tree pruning | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search state tree pruning posted by vitalik buterin on june 26, 2015 research & development one of the important issues that has been brought up over the course of the olympic stress-net release is the large amount of data that clients are required to store; over little more than three months of operation, and particularly during the last month, the amount of data in each ethereum client's blockchain folder has ballooned to an impressive 10-40 gigabytes, depending on which client you are using and whether or not compression is enabled. although it is important to note that this is indeed a stress test scenario where users are incentivized to dump transactions on the blockchain paying only the free test-ether as a transaction fee, and transaction throughput levels are thus several times higher than bitcoin, it is nevertheless a legitimate concern for users, who in many cases do not have hundreds of gigabytes to spare on storing other people's transaction histories. first of all, let us begin by exploring why the current ethereum client database is so large. ethereum, unlike bitcoin, has the property that every block contains something called the "state root": the root hash of a specialized kind of merkle tree which stores the entire state of the system: all account balances, contract storage, contract code and account nonces are inside. the purpose of this is simple: it allows a node given only the last block, together with some assurance that the last block actually is the most recent block, to "synchronize" with the blockchain extremely quickly without processing any historical transactions, by simply downloading the rest of the tree from nodes in the network (the proposed hashlookup wire protocol message will faciliate this), verifying that the tree is correct by checking that all of the hashes match up, and then proceeding from there. in a fully decentralized context, this will likely be done through an advanced version of bitcoin's headers-first-verification strategy, which will look roughly as follows: download as many block headers as the client can get its hands on. determine the header which is on the end of the longest chain. starting from that header, go back 100 blocks for safety, and call the block at that position p100(h) ("the hundredth-generation grandparent of the head") download the state tree from the state root of p100(h), using the hashlookup opcode (note that after the first one or two rounds, this can be parallelized among as many peers as desired). verify that all parts of the tree match up. proceed normally from there. for light clients, the state root is even more advantageous: they can immediately determine the exact balance and status of any account by simply asking the network for a particular branch of the tree, without needing to follow bitcoin's multi-step 1-of-n "ask for all transaction outputs, then ask for all transactions spending those outputs, and take the remainder" light-client model. however, this state tree mechanism has an important disadvantage if implemented naively: the intermediate nodes in the tree greatly increase the amount of disk space required to store all the data. to see why, consider this diagram here: the change in the tree during each individual block is fairly small, and the magic of the tree as a data structure is that most of the data can simply be referenced twice without being copied. however, even still, for every change to the state that is made, a logarithmically large number of nodes (ie. ~5 at 1000 nodes, ~10 at 1000000 nodes, ~15 at 1000000000 nodes) need to be stored twice, one version for the old tree and one version for the new trie. eventually, as a node processes every block, we can thus expect the total disk space utilization to be, in computer science terms, roughly o(n*log(n)), where n is the transaction load. in practical terms, the ethereum blockchain is only 1.3 gigabytes, but the size of the database including all these extra nodes is 10-40 gigabytes. so, what can we do? one backward-looking fix is to simply go ahead and implement headers-first syncing, essentially resetting new users' hard disk consumption to zero, and allowing users to keep their hard disk consumption low by re-syncing every one or two months, but that is a somewhat ugly solution. the alternative approach is to implement state tree pruning: essentially, use reference counting to track when nodes in the tree (here using "node" in the computer-science term meaning "piece of data that is somewhere in a graph or tree structure", not "computer on the network") drop out of the tree, and at that point put them on "death row": unless the node somehow becomes used again within the next x blocks (eg. x = 5000), after that number of blocks pass the node should be permanently deleted from the database. essentially, we store the tree nodes that are part of the current state, and we even store recent history, but we do not store history older than 5000 blocks. x should be set as low as possible to conserve space, but setting x too low compromises robustness: once this technique is implemented, a node cannot revert back more than x blocks without essentially completely restarting synchronization. now, let's see how this approach can be implemented fully, taking into account all of the corner cases: when processing a block with number n, keep track of all nodes (in the state, tree and receipt trees) whose reference count drops to zero. place the hashes of these nodes into a "death row" database in some kind of data structure so that the list can later be recalled by block number (specifically, block number n + x), and mark the node database entry itself as being deletion-worthy at block n + x. if a node that is on death row gets re-instated (a practical example of this is account a acquiring some particular balance/nonce/code/storage combination f, then switching to a different value g, and then account b acquiring state f while the node for f is on death row), then increase its reference count back to one. if that node is deleted again at some future block m (with m > n), then put it back on the future block's death row to be deleted at block m + x. when you get to processing block n + x, recall the list of hashes that you logged back during block n. check the node associated with each hash; if the node is still marked for deletion during that specific block (ie. not reinstated, and importantly not reinstated and then re-marked for deletion later), delete it. delete the list of hashes in the death row database as well. sometimes, the new head of a chain will not be on top of the previous head and you will need to revert a block. for these cases, you will need to keep in the database a journal of all changes to reference counts (that's "journal" as in journaling file systems; essentially an ordered list of the changes made); when reverting a block, delete the death row list generated when producing that block, and undo the changes made according to the journal (and delete the journal when you're done). when processing a block, delete the journal at block n x; you are not capable of reverting more than x blocks anyway, so the journal is superfluous (and, if kept, would in fact defeat the whole point of pruning). once this is done, the database should only be storing state nodes associated with the last x blocks, so you will still have all the information you need from those blocks but nothing more. on top of this, there are further optimizations. particularly, after x blocks, transaction and receipt trees should be deleted entirely, and even blocks may arguably be deleted as well although there is an important argument for keeping some subset of "archive nodes" that store absolutely everything so as to help the rest of the network acquire the data that it needs. now, how much savings can this give us? as it turns out, quite a lot! particularly, if we were to take the ultimate daredevil route and go x = 0 (ie. lose absolutely all ability to handle even single-block forks, storing no history whatsoever), then the size of the database would essentially be the size of the state: a value which, even now (this data was grabbed at block 670000) stands at roughly 40 megabytes the majority of which is made up of accounts like this one with storage slots filled to deliberately spam the network. at x = 100000, we would get essentially the current size of 10-40 gigabytes, as most of the growth happened in the last hundred thousand blocks, and the extra space required for storing journals and death row lists would make up the rest of the difference. at every value in between, we can expect the disk space growth to be linear (ie. x = 10000 would take us about ninety percent of the way there to near-zero). note that we may want to pursue a hybrid strategy: keeping every block but not every state tree node; in this case, we would need to add roughly 1.4 gigabytes to store the block data. it's important to note that the cause of the blockchain size is not fast block times; currently, the block headers of the last three months make up roughly 300 megabytes, and the rest is transactions of the last one month, so at high levels of usage we can expect to continue to see transactions dominate. that said, light clients will also need to prune block headers if they are to survive in low-memory circumstances. the strategy described above has been implemented in a very early alpha form in pyeth; it will be implemented properly in all clients in due time after frontier launches, as such storage bloat is only a medium-term and not a short-term scalability concern. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements ethereum and oracles | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search ethereum and oracles posted by vitalik buterin on july 22, 2014 research & development one of the more popular proposals for implementing smart contracts differently from the way they are typically presented in ethereum is through the concept of oracles. essentially, instead of a long-running contract being run directly on the blockchain, all funds that are intended to go into the contract would instead go into an m-of-n multisig address controlled by a set of specialized entities called "oracles", and the contract code would be simultaneously sent to all of these entities. every time someone wants to send a message to the contract, they would send the message to the oracles. the oracles would run the code, and if the code execution leads to a withdrawal from the contract to some particular address then the oracles circulate a transaction sending the funds and sign it. the approach is still low-trust, as no single oracle has the ability to unilaterally withdraw the funds, but it has a number of particular advantages: not every node in the blockchain needs to perform the computation only a small number of oracles do it theoretically does not require as a platform anything more complicated than bitcoin or ripple as they currently stand contracts have a somewhat higher degree of privacy although exit transactions are still all visible, internal computations may not be. the scheme can also be augmented with secure multiparty computation protocols so the contract can even contain private information (something that would take efficient and secure obfuscation to work directly on ethereum) contracts can rely on external information (eg. currency prices, weather) since it is much easier for n nodes to come to consensus on the result of an http request than an entire blockchain. in fact, they can even rely on data from proprietary apis, if the oracles subscribe to the apis and pass along the costs to the contract users. given all of these advantages, it is undeniably clear that oracles have the potential to be a very useful paradigm for smart contracts going forward. however, the key question is, how will oracle-based computation and blockchain-based computation, as in ethereum, interact with each other? oracles are not always better first of all, one important point to make is that it will not always be the case that the oracle-based method of contract execution will be more efficient than the blockchain-based approach (not to mention non-currency/non-contract uses of the blockchain such as name registries and the people's republic of doug where oracle systems do not even begin to apply). a common misconception is that the primary feature of ethereum is that it is turing-complete, and so while bitcoin only allows quick scripts for verification ethereum contracts are means to do much harder and computationally intensive tasks. this is arguably a misconception. the primary feature of ethereum is not turing-completeness; in fact, we have a section in our whitepaper which makes the argument that even if we explicitly removed the ability of ethereum contracts to be turing-complete it would actually change very little and there would still be a need for "gas". in order to make contracts truly statically analyzable, we would need to go so far as to remove the first-class-citizen property (namely, the fact that contracts can create and call other contracts), at which point ethereum would have very limited utility. rather, the primary feature of ethereum is state ethereum accounts can contain not just a balance and code, but also arbitrary data, allowing for multi-step contracts, long-running contracts such as dos/dacs/daos and particularly non-financial blockchain-based applications to emerge. for example, consider the following contract: init: contract.storage[0] = msg.data[0] # limited account contract.storage[1] = msg.data[1] # unlimited account contract.storage[2] = block.timestamp # time last accessed code: if msg.sender == contract.storage[0]: last_accessed = contract.storage[2] balance_avail = contract.storage[3] # withdrawal limit is 1 finney per second, maximum 10000 ether balance_avail += 10^15 * (block.timestamp last_accessed) if balance_avail > 10^22: balance_avail = 10^22 if msg.data[1] <= balance_avail: send(msg.data[0], msg.data[1]) contract.storage[3] = balance_avail msg.data[1] contract.storage[2] = block.timestamp # unlimited account has no restrictions elif msg.sender == contact.storage[1]: send(msg.data[0], msg.data[1]) this contract is pretty straightforward. it is an account with two access keys, where the first key has a withdrawal limit and the second key does not. you can think of it as a cold/hot wallet setup, except that you do not need to periodically go to the cold wallet to refill unless you want to withdraw a large amount of ether all at once. if a message is sent with data [dest, value], then if the sender is the first account it can send up to a certain limit of ether, and the limit refills at the rate of 1 finney per second (ie. 86.4 ether per day). if the sender is the second account, then the account contract sends the desired amount of ether to the desired destination with no restrictions. now, let's see what expensive operations are required to execute here, specifically for a withdrawal with the limited key: an elliptic curve verification to verify the transaction 2 storage database reads to get the last access time and last withdrawable balance 1 storage database write to record the balance changes that result from the sending transaction 2 storage database writes to write the new last access time and withdrawable balance there are also a couple dozen stack operations and memory reads/writes, but these are much faster than database and cryptography ops so we will not count them. the storage database reads can be made efficient with caching, although the writes will require a few hashes each to rewrite the patricia tree so they are not as easy; that's why sload has a gas cost of 20 but sstore has a cost of up to 200. additionally, the entire transaction should take about 160 bytes, the serpent code takes up 180 bytes, and the four storage slots take up 100-150 bytes hence, 350 bytes one-time cost and 160 bytes bandwitdh per transaction. now, consider this contract with a multisig oracle. the same operations will need to be done, but only on a few servers so the cost is negligible. however, when the multisig transaction is sent to bitcoin, if the multisig is a 3-of-5 then three elliptic curve verifications will be required, and the transaction will require 65 bytes per signature plus 20 bytes per public key so it will take about 350-400 bytes altogether (including also metadata and inputs). the blockchain storage cost will be around 50 bytes per utxo (as opposed to a static 350 in ethereum). hence, assuming that an elliptic curve verification takes longer than a few hashes (it does), the blockchain-based approach is actually easier. the reason why this example is so favorable is because it is a perfect example of how ethereum is about state and not turing-completeness: no loops were used, but the magic of the contract came from the fact that a running record of the withdrawal limit could be maintained inside the contract. (note: advanced cryptographers may note that there is a specialized type of threshold signature that actually requires only one verification operation even if a large number of oracles are used to produce it. however, if we use a currency with such a feature built-in, then we are already abandoning bitcoin's existing infrastructure and network effect; in that case, why not just use the ethereum contract?) but sometimes they are at other times, however, oracles do make sense. the most common case that will appear in reality is the case of external data; sometimes, you want a financial contract that uses the price of the us dollar, and you can't cryptographically determine that just by doing a few hashes and measuring ratios. in this case, oracles are absolutely necessary. another important case is smart contracts that actually are very hard to evaluate. for example, if you are purchasing computational resources from a decentralized cloud computing application, verifying that computations were done legitimately is not a task that the ethereum blockchain can cheaply handle. for most classes of computation, verifying that they were done correctly takes exactly as long as doing them in the first place, so the only way to practically do such a thing is through occasional spot-checking using, well, oracles. another cloud-computing use case for oracles, although in this context we do not think of them as such, is file storage you absolutely do not want to back up your 1gb hard drive onto the blockchain. an additional use-case, already mentioned above, is privacy. sometimes, you may not want the details of your financial contracts public, so doing everything on-chain may not be the best idea. sure, you can use standard-form contracts, and people won't know that it's you who is making a contract for difference between eth and usd at 5:1 leverage, but the information leakage is still high. in those cases, you may want to limit what is done on-chain and do most things off-chain. so how can they work together so we have these two paradigms of total on-chain and partial on-chain, and they both have their relative strengths and weaknesses. however, the question is, are the two really purely competitive? the answer is, as it turns out, no. to further this point, here are a few particular examples: schellingcoin incentivized decentralized oracles. the schellingcoin protocol is a proof-of-concept that shows how we can create a decentralized oracle protocol that is incentive-compatible: have a two-step commitment protocol so that oracles do not initially know what each other's answers are, and then at the end have an ethereum contract reward those oracles that are closest to the median. this incentivizes everyone to respond with the truth, since it is very difficult to coordinate on a lie. an independently conceived alternative, truthcoin, does a similar thing for prediction markets with binary outcomes (eg. did the toronto maple leafs win the world cup?). verifiable computation oracles when the oracles in question are executing moderately computationally intensive code, then we can actually go beyond the admittedly flaky and untested economics of the schellingcoin/truthcoin protocols. the idea is as follows. by default, we have m of n oracles running the code and providing their votes on the answers. however, when an oracle is perceived to vote incorrectly, that oracles can be "challenged". at that point, the oracle must provide the code to the blockchain, the blockchain checks the code against a pre-provided hash and runs the code itself, and sees if the result matches. if the result does not match, or if the oracle never replies to the challenge, then it loses its security deposit. the game-theoretic equilibrium here is for there to be no cheating at all, since any attempt at cheating necessarily harms some other party and so that party has the incentive to perform a check. signature batching one of the problems that i pointed out with the multisig oracle approach above is signature bloat: if you have three oracles signing everything, then that's 195 extra bytes in the blockchain and three expensive verification operations per transaction. however, with ethereum we can be somewhat more clever we can come up with a specialized "oracle contract", to which oracles can submit a single transaction with a single signature with a large number of votes batched together: [addr1, vote1, addr2, vote2 ... ]. the oracle contract then processes the entire list of votes and updates all of the multisig voting pools contained inside it simultaneously. thus, one signature could be used to back an arbitrarily large number of votes, reducing the scalability concerns substantially. blockchain-based auditing the concept of oracle-based computation can actually go much further than the "bitcoin multisig oracle" (or, for that matter, ethereum multisig oracle) idea. the extreme is an approach where oracles also decide the one thing that the bitcoin-based schemes still leave the blockchain to decide: the order of transactions. if we abandon this requirement, then it is possible to achieve much higher degrees of efficiency by having an oracle maintain a centralized database of transactions and state as they come, providing a signed record of each new balance sheet as a transaction is applied, allowing for applications like microtransactions and high-frequency trading. however, this has obvious trust-problems; particularly, what if the oracle double-spends? fortunately, we can set up an ethereum contract to solve the problem. much like the verifiable computation example above, the idea is that by default everything would run entirely on the oracle, but if the oracle chooses to sign two different balance sheets that are the result of incompatible transactions then those two signatures can be imported into ethereum, and the contract will verify that those two signatures are valid, and if they are the contract will take away the oracle's security deposit. more complicated schemes to deal with other attack vectors are also possible. verifiable secure multiparty computation in the case where you are using oracles specifically for the purpose of maintaining private data, you can set up a protocol where the oracles securely choose a new secret key using multiparty random number generation every 24 hours, sign a message with the old key to prove to the world that the new key has authority, and then have to submit all of the computations that they made using the old key to the ethereum blockchain for verification. the old key would be revealed, but it would be useless since a message transferring ownership rights to the new key is already in the blockchain several blocks before. any malfeasance or nonfeasance revealed in the audit would lead to the loss of a security deposit. the larger overarching point of all this is that the primary raison d'être of ethereum is not just to serve as a smart contract engine; it is more generally to serve as a world-wide trust-free decentralized computer, albeit with the disadvantages that it can hold no secrets and it is about ten thousand times slower than a traditional machine. the work in developing cryptoeconomic protocols to ensure that ordinary people have access to reliable, trustworthy and efficient markets and institutions is not nearly done, and the most exciting end-user-centric innovation is likely what will be built on top. it is entirely possible to have systems which use ethereum for one thing, an m-of-n oracle setup for another thing, and some alternative network like maidsafe for something else; base-level protocols are your servant, not your master. special thanks to vlad zamfir for some of the ideas behind combining oracles and ethereum previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-1884: repricing for trie-size-dependent opcodes ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-1884: repricing for trie-size-dependent opcodes authors martin holst swende (@holiman) created 2019-03-28 requires eip-150, eip-1052 table of contents simple summary abstract motivation specification rationale sload balance extcodehash backwards compatibility test cases implementation selfbalance security considerations copyright simple summary this eip proposes repricing certain opcodes, to obtain a good balance between gas expenditure and resource consumption. abstract the growth of the ethereum state has caused certain opcodes to be more resource-intensive at this point than they were previously. this eip proposes to raise the gascost for those opcodes. motivation an imbalance between the price of an operation and the resource consumption (cpu time, memory etc) has several drawbacks: it could be used for attacks, by filling blocks with underpriced operations which causes excessive block processing time. underpriced opcodes cause a skewed block gas limit, where sometimes blocks finish quickly but other blocks with similar gas use finish slowly. if operations are well-balanced, we can maximise the block gaslimit and have a more stable processing time. specification at block n, the sload (0x54) operation changes from 200 to 800 gas, the balance (0x31) operation changes from 400 to 700 gas, the extcodehash (0x3f) operation changes from 400 to 700 gas, a new opcode, selfbalance is introduced at 0x47. selfbalance pops 0 arguments off the stack, selfbalance pushes the balance of the current address to the stack, selfbalance is priced as gasfaststep, at 5 gas. rationale here are two charts, taken from a full sync using geth. the execution time was measured for every opcode, and aggregated for 10k blocks. these bar charts show the top 25 ‘heavy’ opcodes in the ranges 5m to 6m and 6m to 7m: note: it can also be seen that the sload moves towards the top position. the gasprice (0x3a) opcode has position one which i believe can be optimized away within the client – which is not the case with sload/balance. here is another chart, showing a full sync with geth. it represents the blocks 0 to 5.7m, and highlights what the block processing time is spent on. it can be seen that storage_reads and account_reads are the two most significant factors contributing to the block processing time. sload sload was repriced at eip-150, from 50 to 200. the following graph shows a go-ethereum full sync, where each data point represents 10k blocks. during those 10k blocks, the execution time for the opcode was aggregated. it can be seen that the repricing at eip-150 caused a steep drop, from around 67 to 23. around block 5m, it started reaching pre-eip-150 levels, and at block 7m it was averaging on around 150 more than double pre-eip-150 levels. increasing the cost of sload by 4 would bring it back down to around 40. it is to be expected that it will rise again in the future, and may need future repricing, unless state clearing efforts are implemented before that happens. balance balance (a.k.a extbalance) is an operation which fetches data from the state trie. it was repriced at eip-150 from 20 to 400. it is comparable to extcodesize and extcodehash, which are priced at 700 already. it has a built-in high variance, since it is often used for checking the balance of this, which is a inherently cheap operation, however, it can be used to lookup the balance of arbitrary account which often require trie (disk) access. in hindsight, it might have been a better choice to have two opcodes: extbalance(address) and selfbalance, and have two different prices. this eip proposes to extend the current opcode set. unfortunately, the opcode span 0x3x is already full, hence the suggestion to place selfbalance in the 0x4x range. as for why it is priced at 5 (gasfaststep) instead of 2 (gasquickstep), like other similar operations: the evm execution engine still needs a lookup into the (cached) trie, and balance, unlike gasprice or timestamp, is not constant during the execution, so it has a bit more inherent overhead. extcodehash extcodehash was introduced in constantinople, with eip-1052. it was priced at 400 with the reasoning: the gas cost is the same as the gas cost for the balance opcode because the execution of the extcodehash requires the same account lookup as in balance. ergo, if we increase balance, we should also increase extcodehash backwards compatibility the changes require a hardfork. the changes have the following consequences: certain calls will become more expensive. default-functions which access the storage and may in some cases require more than2300 gas (the minimum gas that is always available in calls). contracts that assume a certain fixed gas cost for calls (or internal sections) may cease to function. a fixed gas cost is specified in erc-165 and implementations of this interface do use the affected opcodes. the erc-165 method supportsinterface must return a bool and use at most 30,000 gas. the two example implementations from the eip were, at the time of writing 586 gas for any input, and 236 gas, but increases linearly with a higher number of supported interfaces it is unlikely that any erc-165 supportsinterface implementation will go above 30.000 gas. that would require that the second variant is used, and thirty:ish interfaces are supported. however, these operations have already been repriced earlier, so there is a historical precedent that ‘the gascost for these operations may change’, which should have prevented such fixed-gas-cost assumptions from being implemented. i expect that certain patterns will be less used, for example the use of multiple modifiers which sloads the same opcode will be merged into one. it may also lead to less log operations containing sloaded values that are not strictly necessary. test cases testcases that should be implemented: test that selfbalance == balance(address), test that balance(this) costs as before, test that selfbalance does not pop from stack gascost verification of sload, extcodehash and selfbalance verify that selfbalance is invalid before istanbul some testcases have been implemented as statetests at https://github.com/holiman/istanbultests/tree/master/generalstatetests implementation this eip has not yet been implemented in any client. both these opcodes have been repriced before, and the client internals for managing reprices are already in place. selfbalance this is the implementation for the new opcode in go-ethereum: func opselfbalance(pc *uint64, interpreter *evminterpreter, contract *contract, memory *memory, stack *stack) ([]byte, error) { stack.push(interpreter.intpool.get().set(interpreter.evm.statedb.getbalance(contract.address()) return nil, nil } security considerations see backwards compatibility section. there are no special edgecases regarding selfbalance, if we define it as balance with address instead of popping an address from the stack – since balance is already well-defined. it should be investigated if solidity contains any hardcoded expectations on the gas cost of these operations. in many cases, a recipient of ether from a call will want to issue a log. the log operation costs 375 plus 375 per topic. if the log also wants to do an sload, this change may make some such transfers fail. copyright copyright and related rights waived via cc0. citation please cite this document as: martin holst swende (@holiman), "eip-1884: repricing for trie-size-dependent opcodes," ethereum improvement proposals, no. 1884, march 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1884. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5505: eip-1155 asset backed nft extension ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5505: eip-1155 asset backed nft extension extends eip-1155 to support crucial operations for asset-backed nfts authors liszechung (@liszechung) created 2022-08-18 discussion link https://ethereum-magicians.org/t/eip-draft-erc1155-asset-backed-nft-extension/10437 requires eip-1155 table of contents abstract motivation specification rationale security considerations copyright abstract to propose an extension of smart contract interfaces for asset-backed, fractionalized projects using the eip-1155 standard such that total acquisition will become possible. this proposal focuses on physical asset, where total acquisition should be able to happen. motivation fractionalized, asset backed nfts face difficulty when someone wants to acquire the whole asset. for example, if someone wants to bring home a fractionalized asset, he needs to buy all nft pieces so he will become the 100% owner. however he could not do so as it is publicly visible that someone is trying to perform a total acquisition in an open environment like ethereum. sellers will take advantage to set unreasonable high prices which hinders the acquisition. or in other cases, nfts are owned by wallets with lost keys, such that the ownership will never be a complete one. we need a way to enable potential total acquisition. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. eip-1155 compliant contracts may implement this eip for adding functionalities to support total acquisition. //set the percentage required for any acquirer to trigger a forced sale //set also the payment token to settle for the acquisition function setforcedsalerequirement( uint128 requiredbp, address erc20token ) public onlyowner //set the unit price to acquire the remaining nfts (100% requiredbp) //suggest to use a time weighted average price for a certain period before reaching the requiredbp //emit forcedsaleset function setforcedsaletwap( uint256 amount ) public onlyowner //acquirer deposit remainingqty*twap //emit forcedsalefinished //after this point, the acquirer is the new owner of the whole asset function execforcedsale ( uint256 amount ) public external payable //burn all nfts and collect funds //emit forcedsaleclaimed function claimforcedsale() public event forcedsaleset( bool isset ) event forcesaleclaimed( uint256 qtyburned, uint256 amountclaimed, address claimer ) rationale native eth is supported by via wrapped ether eip-20. after forcedsale is set, the remaining nfts metadata should be updated to reflect the nfts are at most valued at the previously set twap price. security considerations the major security risks considered include the execution of the forcedsale is only executed by the contract owner, after a governance proposal. if there is any governance attack, the forcedsale twap price might be manipulated on a specific timing. the governance structure for using this extension should consider adding a council to safeguard the fairness of the forcedsale. payment tokens are deposited into the contract account when forcedsale is executed. these tokens will then await the minority holders to withdraw on burning the nft. there might be a potential security risk. copyright copyright and related rights waived via cc0. citation please cite this document as: liszechung (@liszechung), "erc-5505: eip-1155 asset backed nft extension [draft]," ethereum improvement proposals, no. 5505, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5505. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1271: standard signature validation method for contracts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-1271: standard signature validation method for contracts standard way to verify a signature when the account is a smart contract authors francisco giordano (@frangio), matt condon (@shrugs), philippe castonguay (@phabc), amir bandeali (@abandeali1), jorge izquierdo (@izqui), bertrand masius (@catageek) created 2018-07-25 table of contents abstract motivation specification rationale backwards compatibility reference implementation security considerations copyright abstract externally owned accounts (eoa) can sign messages with their associated private keys, but currently contracts cannot. we propose a standard way for any contracts to verify whether a signature on a behalf of a given contract is valid. this is possible via the implementation of a isvalidsignature(hash, signature) function on the signing contract, which can be called to validate a signature. motivation there are and will be many contracts that want to utilize signed messages for validation of rights-to-move assets or other purposes. in order for these contracts to be able to support non externally owned accounts (i.e., contract owners), we need a standard mechanism by which a contract can indicate whether a given signature is valid or not on its behalf. one example of an application that requires signatures to be provided would be decentralized exchanges with off-chain orderbook, where buy/sell orders are signed messages. in these applications, eoas sign orders, signaling their desire to buy/sell a given asset and giving explicit permissions to the exchange smart contracts to conclude a trade via a signature. when it comes to contracts however, regular signatures are not possible since contracts do not possess a private key, hence this proposal. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. pragma solidity ^0.5.0; contract erc1271 { // bytes4(keccak256("isvalidsignature(bytes32,bytes)") bytes4 constant internal magicvalue = 0x1626ba7e; /** * @dev should return whether the signature provided is valid for the provided hash * @param _hash hash of the data to be signed * @param _signature signature byte array associated with _hash * * must return the bytes4 magic value 0x1626ba7e when function passes. * must not modify state (using staticcall for solc < 0.5, view modifier for solc > 0.5) * must allow external calls */ function isvalidsignature( bytes32 _hash, bytes memory _signature) public view returns (bytes4 magicvalue); } isvalidsignature can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), eoa dependent (e.g. signers authorization level within smart wallet), signature scheme dependent (e.g. ecdsa, multisig, bls), etc. this function should be implemented by contracts which desire to sign messages (e.g. smart contract wallets, daos, multisignature wallets, etc.) applications wanting to support contract signatures should call this method if the signer is a contract. rationale we believe the name of the proposed function to be appropriate considering that an authorized signers providing proper signatures for a given data would see their signature as “valid” by the signing contract. hence, a signed action message is only valid when the signer is authorized to perform a given action on the behalf of a smart wallet. two arguments are provided for simplicity of separating the hash signed from the signature. a bytes32 hash is used instead of the unhashed message for simplicity, since contracts could expect a certain hashing function that is not standard, such as with eip-712. isvalidsignature() should not be able to modify states in order to prevent gastoken minting or similar attack vectors. again, this is to simplify the implementation surface of the function for better standardization and to allow off-chain contract queries. the specific return value is expected to be returned instead of a boolean in order to have stricter and simpler verification of a signature. backwards compatibility this eip is backward compatible with previous work on signature validation since this method is specific to contract based signatures and not eoa signatures. reference implementation example implementation of a signing contract: /** * @notice verifies that the signer is the owner of the signing contract. */ function isvalidsignature( bytes32 _hash, bytes calldata _signature ) external override view returns (bytes4) { // validate signatures if (recoversigner(_hash, _signature) == owner) { return 0x1626ba7e; } else { return 0xffffffff; } } /** * @notice recover the signer of hash, assuming it's an eoa account * @dev only for ethsign signatures * @param _hash hash of message that was signed * @param _signature signature encoded as (bytes32 r, bytes32 s, uint8 v) */ function recoversigner( bytes32 _hash, bytes memory _signature ) internal pure returns (address signer) { require(_signature.length == 65, "signaturevalidator#recoversigner: invalid signature length"); // variables are not scoped in solidity. uint8 v = uint8(_signature[64]); bytes32 r = _signature.readbytes32(0); bytes32 s = _signature.readbytes32(32); // eip-2 still allows signature malleability for ecrecover(). remove this possibility and make the signature // unique. appendix f in the ethereum yellow paper (https://ethereum.github.io/yellowpaper/paper.pdf), defines // the valid range for s in (281): 0 < s < secp256k1n ÷ 2 + 1, and for v in (282): v ∈ {27, 28}. most // signatures from current libraries generate a unique signature with an s-value in the lower half order. // // if your library generates malleable signatures, such as s-values in the upper range, calculate a new s-value // with 0xfffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364141 s1 and flip v from 27 to 28 or // vice versa. if your library also generates signatures with 0/1 for v instead 27/28, add 27 to v to accept // these malleable signatures as well. // // source openzeppelin // https://github.com/openzeppelin/openzeppelin-contracts/blob/master/contracts/cryptography/ecdsa.sol if (uint256(s) > 0x7fffffffffffffffffffffffffffffff5d576e7357a4501ddfe92f46681b20a0) { revert("signaturevalidator#recoversigner: invalid signature 's' value"); } if (v != 27 && v != 28) { revert("signaturevalidator#recoversigner: invalid signature 'v' value"); } // recover ecdsa signer signer = ecrecover(_hash, v, r, s); // prevent signer from being 0x0 require( signer != address(0x0), "signaturevalidator#recoversigner: invalid_signer" ); return signer; } example implementation of a contract calling the isvalidsignature() function on an external signing contract ; function callerc1271isvalidsignature( address _addr, bytes32 _hash, bytes calldata _signature ) external view { bytes4 result = ierc1271wallet(_addr).isvalidsignature(_hash, _signature); require(result == 0x1626ba7e, "invalid_signature"); } security considerations since there are no gas-limit expected for calling the isvalidsignature() function, it is possible that some implementation will consume a large amount of gas. it is therefore important to not hardcode an amount of gas sent when calling this method on an external contract as it could prevent the validation of certain signatures. note also that each contract implementing this method is responsible to ensure that the signature passed is indeed valid, otherwise catastrophic outcomes are to be expected. copyright copyright and related rights waived via cc0. citation please cite this document as: francisco giordano (@frangio), matt condon (@shrugs), philippe castonguay (@phabc), amir bandeali (@abandeali1), jorge izquierdo (@izqui), bertrand masius (@catageek), "erc-1271: standard signature validation method for contracts," ethereum improvement proposals, no. 1271, july 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1271. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1965: method to check if a chainid is valid at a specific block number ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1965: method to check if a chainid is valid at a specific block number authors ronan sandford (@wighawag) created 2019-04-20 discussion link https://ethereum-magicians.org/t/eip-1965-valid-chainid-for-specific-blocknumber-protect-all-forks/3181 requires eip-155 table of contents abstract motivation specification rationale backwards compatibility references copyright abstract this eip adds a precompile that returns whether a specific chainid (eip-155 unique identifier) is valid at a specific blocknumber. chainid are assumed to be valid up to the blocknumber at which they get replaced by a new chainid. motivation eip-155 proposes to use the chain id to prevent the replay of transactions between different chains. it would be a great benefit to have the same possibility inside smart contracts when handling off-chain message signatures, especially for layer 2 signature schemes using eip-712. eip-1344 is attempting to solve this by giving smart contract access to the tip of the chainid history. this is insuficient as such value is changing. hence why eip-1344 describes a contract based solution to work around the problem. it would be better to solve it in a simpler, cheaper and safer manner, removing the potential risk of misuse present in eip-1344. furthermore eip-1344 can’t protect replay properly for minority-led hardfork as the caching system cannot guarantee accuracy of the blocknumber at which the new chainid has been introduced. eip-1959 solves the issue of eip-1344 but do not attempt to protect from minority-led hardfork as mentioned in the rationale. we consider this a mistake, since it remove some freedom to fork. we consider that all fork should be given equal oportunities. and while there will always be issues we can’t solve for the majority that ignore a particular fork, users that decide to use both the minority-fork and the majority-chain should be protected from replay without having to wait for the majority chain to update its chainid. specification adds a new precompile which uses 2 argument : a 32 bytes value that represent the chainid to test and a 32 bytes value representing the blocknumber at which the chainid is tested. it return 0x1 if the chainid is valid at the specific blocknumber, 0x0 otherwise. note that chainid are considered valid up to the blocknumber at which they are replaced. so they are valid for every blocknumber past their replacement. the operation will costs no more than g_blockhash + g_verylow to execute. this could be lower as chainid are only introduced during hardfork. the cost of the operation might need to be adjusted later as the number of chainid in the history of the chain grows. note though that the alternative to keep track of old chainid is to implement a smart contract based caching solution as eip-1344 proposes comes with an overall higher gas cost and exhibit issues for minority-led hardfork (see rationale section below). as such the gas cost is simply a necessary cost for the feature. rationale the rationale at eip-1959 applies here as well too : an opcode is better than a caching system for past chainid, it is cheaper, safer and do not include gaps. direct access to the latest chainid is dangerous since it make it easy for contract to use it as a replay protection mechanism while preventing otherwise valid old messages to be valid after a fork that change the chainid. this can have disastrous consequences on users. all off-chain messaged signed before a fork should be valid across all side of the fork. the only difference is that this current proposal propose a solution to protect hardfork led by a minority. to summarize there is 2 possible fork scenario : 1) the majority decide to make an hardfork but a minority disagree with it (etc is such example). the fork is planned for block x. if the majority is not taking any action to automate the process of assigning a different chainid for both, the minority has plenty of time to plan for a chainid upgrade to happen at that same block x. now if they do not do it, their users will face the problem that their messages will be replayable on the majority chain (note that this is not true the other way around as we assume the majority decided to change the chainid). as such there is no reason that they’ll leave it that way. 2) a minority decide to create an hardfork that the majority disagree with (or simply ignore). now, the same as above can happen but since we are talking about a minority there is a chance that the majority do not care about the minority. in that case, there would be no incentive for the majority to upgrade the chainid. this means that user of both side of the fork will have the messages meant for the majority chain replayable on the minority-chain (even if this one changed its chainid) unless extra precaution is taken. the solution is to add the blocknumber representing the time at which the message was signed and use it as an argument to the opcode proposed here. this way, when the minority forks with a new chainid, the previous chainid become invalid from that time onward. so new messages destinated to the majority chain can’t be replayed on the minority fork. backwards compatibility eip-712 is still in draft but would need to be updated to include the blocknumber as part of the values that wallets need to verify for the protection of their users. since chainid and blocknumber will vary, they should not be part of the domain separator (meant to be generated once) but another part of the message. while the pair could be optional for contract that do not care about replays or have other ways to prevent them, if chainid is present, the blocknumber must be present too. and if any of them is present, wallet need to ensure that the chainid is indeed the latest one of the chain being used, while the blocknumber is the latest one at the point of signing. during fork transition, the wallet can use the blocknumber to know which chainid to use. references this was previously suggested as part of eip1959 discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: ronan sandford (@wighawag), "eip-1965: method to check if a chainid is valid at a specific block number [draft]," ethereum improvement proposals, no. 1965, april 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1965. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3041: adds `basefee` to `eth_getblockbyhash` ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3041: adds `basefee` to `eth_getblockbyhash` authors abdelhamid bakhta (@abdelhamidbakhta) created 2020-10-13 discussion link https://ethereum-magicians.org/t/eip-3041-add-basefee-in-eth-getblockbyhash-response/4825 requires eip-1474, eip-1559 table of contents simple summary abstract motivation specification eth_getblockbyhash rationale backwards compatibility security considerations copyright simple summary add basefee field to eth_getblockbyhash rpc endpoint response. abstract adds basefee property to the eth_getblockbyhash json-rpc request result object. this property will contain the value of the base fee for any block after the eip-1559 fork. motivation eip-1559 introduces a base fee per gas in protocol. this value is maintained under consensus as a new field in the block header structure. users may need value of the base fee at a given block. base fee value is important to make gas price predictions more accurate. specification eth_getblockbyhash description returns information about a block specified by hash. every block returned by this endpoint whose block number is before the eip-1559 fork block must not include a basefee field. every block returned by this endpoint whose block number is on or after the eip-1559 fork block must include a basefee field. parameters parameters remain unchanged. returns for the full specification of eth_getblockbyhash see eip-1474. add a new json field to the result object for block headers containing a base fee (post eip-1559 fork block). {quantity} basefee base fee for this block example # request curl -x post --data '{ "id": 1559, "jsonrpc": "2.0", "method": "eth_getblockbyhash", "params":["0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", true] }' # response { "id": 1559, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extradata": "0x0000000000000000000000000000000000000000000000000000000000000000", "basefee": "0x7" "gaslimit": "0x9f759", "gasused": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsbloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parenthash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateroot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totaldifficulty": "0x027f07", "transactions": [] "transactionsroot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [] } } rationale the addition of a single parameter instead of introducing a whole new endpoint was the simplest change that would be easiest to get integrated. for backward compatibility we decided to not include the base fee in the response for pre-1559 blocks. backwards compatibility backwards compatible. calls related to block prior to eip-1559 fork block will omit the base fee field in the response. security considerations the added field (basefee) is informational and does not introduce technical security issues. copyright copyright and related rights waived via cc0. citation please cite this document as: abdelhamid bakhta (@abdelhamidbakhta), "eip-3041: adds `basefee` to `eth_getblockbyhash` [draft]," ethereum improvement proposals, no. 3041, october 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3041. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-7044: perpetually valid signed voluntary exits ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: core eip-7044: perpetually valid signed voluntary exits lock voluntary exit signature domain on capella for perpetual validity authors lion (@dapplion) created 2023-05-18 last call deadline 2024-02-15 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification consensus layer execution layer rationale backwards compatibility test cases security considerations copyright abstract lock validator voluntary exit signature domain on capella for perpetual validity. currently, signed voluntary exits are only valid for two upgrades. motivation currently, signed voluntary exits are valid up-to only two upgrades for block inclusion due to the beacon chain state considering only the current and previous fork version. this limitation increases the complexity of some staking operations, specifically those in which the staking operator (holder of active key) is distinct from the owner of the funds (holder of the withdrawal credential). because voluntary exits can only be signed by the active key, such a relationship requires the exchange of signed exits ahead of time for an unbounded number of forks. the limited validity of voluntary exits was originally motivated to isolate them in the event of a hard fork that results in two maintained chains. if fork a and b exist and a validator operates on both, if they send an exit, it will be replayable on both. however, this possibility is not sufficient to justify the ux degradation exposed above, as no funds are at risk and the staker can re-stake on one or both of the chains. specification consensus layer specification changes are built into the consensus specs deneb upgrade. the specific makes one change to the state transition function: modify process_voluntary_exit to compute the signing domain and root fixed on capella_fork_version. additionally, the voluntary_exit gossip conditions are implicitly modified to support this change. to make the change backwards compatible the signature domain is locked on the capella fork execution layer this specification does not require any changes to the execution layer. rationale perpetually valid signed voluntary exits allow simpler staking operation designs. it also aligns the ux of such objects to blstoexecutionchanges and deposits, such that downstream tooling does not need to be updated with fork version information. backwards compatibility this change is backwards compatible to the consensus layer of ethereum block processing logic. the expectation of future validity of exits is not forward compatible. specifically, users who have already pre-signed exits utilizing the deneb fork domain with an expectation of their validity should be aware that these pre-signed exits will no longer be recognized as valid. consequently, users should adjust their approach moving forward. for continued validity across forks, including deneb and subsequent forks, users should ensure that their exits are signed using the capella fork domain. there are no forwards/backwards compatibility issues with the execution layer. test cases test cases are work-in-progress within the standard consensus layer tests. security considerations the divergent signature domains across forked networks would previously have prevented the replay of voluntaryexits after two hard forks. this specification change causes the replay protection to no longer exist. these potential replays could impact individual stakers on both sides of a fork, but does not put funds at risk and does not impact the security of the chain. copyright copyright and related rights waived via cc0. citation please cite this document as: lion (@dapplion), "eip-7044: perpetually valid signed voluntary exits [draft]," ethereum improvement proposals, no. 7044, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7044. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-4337: account abstraction using alt mempool ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-4337: account abstraction using alt mempool an account abstraction proposal which completely avoids consensus-layer protocol changes, instead relying on higher-layer infrastructure. authors vitalik buterin (@vbuterin), yoav weiss (@yoavw), dror tirosh (@drortirosh), shahaf nacson (@shahafn), alex forshtat (@forshtat), kristof gazso (@kristofgazso), tjaden hess (@tjade273) created 2021-09-29 discussion link https://ethereum-magicians.org/t/erc-4337-account-abstraction-via-entry-point-contract-specification/7160 table of contents abstract motivation specification definitions required entry point contract functionality extension: paymasters client behavior upon receiving a useroperation simulation bundling reputation scoring and throttling/banning for global entities rationale paymasters first-time account creation entry point upgrading rpc methods (eth namespace) rpc methods (debug namespace) backwards compatibility reference implementation security considerations copyright abstract an account abstraction proposal which completely avoids the need for consensus-layer protocol changes. instead of adding new protocol features and changing the bottom-layer transaction type, this proposal instead introduces a higher-layer pseudo-transaction object called a useroperation. users send useroperation objects into a separate mempool. a special class of actor called bundlers package up a set of these objects into a transaction making a handleops call to a special contract, and that transaction then gets included in a block. motivation see also https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020 and the links therein for historical work and motivation, and eip-2938 for a consensus layer proposal for implementing the same goal. this proposal takes a different approach, avoiding any adjustments to the consensus layer. it seeks to achieve the following goals: achieve the key goal of account abstraction: allow users to use smart contract wallets containing arbitrary verification logic instead of eoas as their primary account. completely remove any need at all for users to also have eoas (as status quo sc wallets and eip-3074 both require) decentralization allow any bundler (think: block builder) to participate in the process of including account-abstracted user operations work with all activity happening over a public mempool; users do not need to know the direct communication addresses (eg. ip, onion) of any specific actors avoid trust assumptions on bundlers do not require any ethereum consensus changes: ethereum consensus layer development is focusing on the merge and later on scalability-oriented features, and there may not be any opportunity for further protocol changes for a long time. hence, to increase the chance of faster adoption, this proposal avoids ethereum consensus changes. try to support other use cases privacy-preserving applications atomic multi-operations (similar goal to eip-3074) pay tx fees with erc-20 tokens, allow developers to pay fees for their users, and eip-3074-like sponsored transaction use cases more generally support aggregated signature (e.g. bls) specification definitions useroperation a structure that describes a transaction to be sent on behalf of a user. to avoid confusion, it is not named “transaction”. like a transaction, it contains “sender”, “to”, “calldata”, “maxfeepergas”, “maxpriorityfee”, “signature”, “nonce” unlike a transaction, it contains several other fields, described below also, the “signature” field usage is not defined by the protocol, but by each account implementation sender the account contract sending a user operation. entrypoint a singleton contract to execute bundles of useroperations. bundlers/clients whitelist the supported entrypoint. bundler a node (block builder) that can handle useroperations, create a valid an entrypoint.handleops() transaction, and add it to the block while it is still valid. this can be achieved by a number of ways: bundler can act as a block builder itself if the bundler is not a block builder, it must work with the block building infrastructure such as mev-boost or other kind of pbs (proposer-builder separation) the bundler can also rely on an experimental eth_sendrawtransactionconditional rpc api if it is available. aggregator a helper contract trusted by accounts to validate an aggregated signature. bundlers/clients whitelist the supported aggregators. to avoid ethereum consensus changes, we do not attempt to create new transaction types for account-abstracted transactions. instead, users package up the action they want their account to take in an abi-encoded struct called a useroperation: field type description sender address the account making the operation nonce uint256 anti-replay parameter (see “semi-abstracted nonce support” ) initcode bytes the initcode of the account (needed if and only if the account is not yet on-chain and needs to be created) calldata bytes the data to pass to the sender during the main execution call callgaslimit uint256 the amount of gas to allocate the main execution call verificationgaslimit uint256 the amount of gas to allocate for the verification step preverificationgas uint256 the amount of gas to pay for to compensate the bundler for pre-verification execution, calldata and any gas overhead that can’t be tracked on-chain maxfeepergas uint256 maximum fee per gas (similar to eip-1559 max_fee_per_gas) maxpriorityfeepergas uint256 maximum priority fee per gas (similar to eip-1559 max_priority_fee_per_gas) paymasteranddata bytes address of paymaster sponsoring the transaction, followed by extra data to send to the paymaster (empty for self-sponsored transaction) signature bytes data passed into the account along with the nonce during the verification step users send useroperation objects to a dedicated user operation mempool. a specialized class of actors called bundlers (either block builders running special-purpose code, or users that can relay transactions to block builders eg. through a bundle marketplace such as flashbots that can guarantee next-block-or-never inclusion) listen in on the user operation mempool, and create bundle transactions. a bundle transaction packages up multiple useroperation objects into a single handleops call to a pre-published global entry point contract. to prevent replay attacks (both cross-chain and multiple entrypoint implementations), the signature should depend on chainid and the entrypoint address. the core interface of the entry point contract is as follows: function handleops(useroperation[] calldata ops, address payable beneficiary); function handleaggregatedops( useropsperaggregator[] calldata opsperaggregator, address payable beneficiary ); struct useropsperaggregator { useroperation[] userops; iaggregator aggregator; bytes signature; } function simulatevalidation(useroperation calldata userop); error validationresult(returninfo returninfo, stakeinfo senderinfo, stakeinfo factoryinfo, stakeinfo paymasterinfo); error validationresultwithaggregation(returninfo returninfo, stakeinfo senderinfo, stakeinfo factoryinfo, stakeinfo paymasterinfo, aggregatorstakeinfo aggregatorinfo); struct returninfo { uint256 preopgas; uint256 prefund; bool sigfailed; uint48 validafter; uint48 validuntil; bytes paymastercontext; } struct stakeinfo { uint256 stake; uint256 unstakedelaysec; } struct aggregatorstakeinfo { address actualaggregator; stakeinfo stakeinfo; } the core interface required for an account to have is: interface iaccount { function validateuserop (useroperation calldata userop, bytes32 userophash, uint256 missingaccountfunds) external returns (uint256 validationdata); } the userophash is a hash over the userop (except signature), entrypoint and chainid. the account: must validate the caller is a trusted entrypoint if the account does not support signature aggregation, it must validate the signature is a valid signature of the userophash, and should return sig_validation_failed (and not revert) on signature mismatch. any other error should revert. must pay the entrypoint (caller) at least the “missingaccountfunds” (which might be zero, in case current account’s deposit is high enough) the account may pay more than this minimum, to cover future transactions (it can always issue withdrawto to retrieve it) the return value must be packed of authorizer, validuntil and validafter timestamps. authorizer 0 for valid signature, 1 to mark signature failure. otherwise, an address of an authorizer contract. this erc defines “signature aggregator” as authorizer. validuntil is 6-byte timestamp value, or zero for “infinite”. the userop is valid only up to this time. validafter is 6-byte timestamp. the userop is valid only after this time. an account that works with aggregated signature, should return its signature aggregator address in the “sigauthorizer” return value of validateuserop. it may ignore the signature field the core interface required by an aggregator is: interface iaggregator { function validateuseropsignature(useroperation calldata userop) external view returns (bytes memory sigforuserop); function aggregatesignatures(useroperation[] calldata userops) external view returns (bytes memory aggregatessignature); function validatesignatures(useroperation[] calldata userops, bytes calldata signature) view external; } if an account uses an aggregator (returns it from validateuserop), then its address is returned by simulatevalidation() reverting with validationresultwithaggregator instead of validationresult to accept the userop, the bundler must call validateuseropsignature() to validate the userop’s signature. aggregatesignatures() must aggregate all userop signature into a single value. note that the above methods are helper method for the bundler. the bundler may use a native library to perform the same validation and aggregation logic. validatesignatures() must validate the aggregated signature matches for all useroperations in the array, and revert otherwise. this method is called on-chain by handleops() semi-abstracted nonce support in ethereum protocol, the sequential transaction nonce value is used as a replay protection method as well as to determine the valid order of transaction being included in blocks. it also contributes to the transaction hash uniqueness, as a transaction by the same sender with the same nonce may not be included in the chain twice. however, requiring a single sequential nonce value is limiting the senders’ ability to define their custom logic with regard to transaction ordering and replay protection. instead of sequential nonce we implement a nonce mechanism that uses a single uint256 nonce value in the useroperation, but treats it as two values: 192-bit “key” 64-bit “sequence” these values are represented on-chain in the entrypoint contract. we define the following method in the entrypoint interface to expose these values: function getnonce(address sender, uint192 key) external view returns (uint256 nonce); for each key the sequence is validated and incremented sequentially and monotonically by the entrypoint for each useroperation, however a new key can be introduced with an arbitrary value at any point. this approach maintains the guarantee of useroperation hash uniqueness on-chain on the protocol level while allowing wallets to implement any custom logic they may need operating on a 192-bit “key” field, while fitting the 32 byte word. reading and validating the nonce when preparing the userop clients may make a view call to this method to determine a valid value for the nonce field. bundler’s validation of a userop should start with getnonce to ensure the transaction has a valid nonce field. if the bundler is willing to accept multiple useroperations by the same sender into their mempool, this bundler is supposed to track the key and sequence pair of the useroperations already added in the mempool. usage examples classic sequential nonce. in order to require the wallet to have classic, sequential nonce, the validation function should perform: require(userop.nonce> 64; if (sig == admin_methodsig) { require(key == admin_key, "wrong nonce-key for admin operation"); } else { require(key == 0, "wrong nonce-key for normal operation"); } using signature aggregators an account signifies it uses signature aggregation returning its address from validateuserop. during simulatevalidation, this aggregator is returned (in the validationresultwithaggregator) the bundler should first accept the aggregator (validate its stake info and that it is not throttled/banned) then it must verify the userop using aggregator.validateuseropsignature() signature aggregator should stake just like a paymaster, unless it is exempt due to not accessing global storage see reputation, throttling and banning section for details. bundlers may throttle down and ban aggregators in case they take too much resources (or revert) when the above methods are called in view mode, or if the signature aggregation fails. required entry point contract functionality there are 2 separate entry point methods: handleops and handleaggregatedops handleops handle userops of accounts that don’t require any signature aggregator. handleaggregatedops can handle a batch that contains userops of multiple aggregators (and also requests without any aggregator) handleaggregatedops performs the same logic below as handleops, but it must transfer the correct aggregator to each userop, and also must call validatesignatures on each aggregator after doing all the per-account validation. the entry point’s handleops function must perform the following steps (we first describe the simpler non-paymaster case). it must make two loops, the verification loop and the execution loop. in the verification loop, the handleops call must perform the following steps for each useroperation: create the account if it does not yet exist, using the initcode provided in the useroperation. if the account does not exist, and the initcode is empty, or does not deploy a contract at the “sender” address, the call must fail. call validateuserop on the account, passing in the useroperation, the required fee and aggregator (if there is one). the account should verify the operation’s signature, and pay the fee if the account considers the operation valid. if any validateuserop call fails, handleops must skip execution of at least that operation, and may revert entirely. validate the account’s deposit in the entrypoint is high enough to cover the max possible cost (cover the already-done verification and max execution gas) in the execution loop, the handleops call must perform the following steps for each useroperation: call the account with the useroperation’s calldata. it’s up to the account to choose how to parse the calldata; an expected workflow is for the account to have an execute function that parses the remaining calldata as a series of one or more calls that the account should make. before accepting a useroperation, bundlers should use an rpc method to locally call the simulatevalidation function of the entry point, to verify that the signature is correct and the operation actually pays fees; see the simulation section below for details. a node/bundler should drop (not add to the mempool) a useroperation that fails the validation extension: paymasters we extend the entry point logic to support paymasters that can sponsor transactions for other users. this feature can be used to allow application developers to subsidize fees for their users, allow users to pay fees with erc-20 tokens and many other use cases. when the paymaster is not equal to the zero address, the entry point implements a different flow: during the verification loop, in addition to calling validateuserop, the handleops execution also must check that the paymaster has enough eth deposited with the entry point to pay for the operation, and then call validatepaymasteruserop on the paymaster to verify that the paymaster is willing to pay for the operation. note that in this case, the validateuserop is called with a missingaccountfunds of 0 to reflect that the account’s deposit is not used for payment for this userop. if the paymaster’s validatepaymasteruserop returns a “context”, then handleops must call postop on the paymaster after making the main execution call. it must guarantee the execution of postop, by making the main execution inside an inner call context, and if the inner call context reverts attempting to call postop again in an outer call context. maliciously crafted paymasters can dos the system. to prevent this, we use a reputation system. paymaster must either limit its storage usage, or have a stake. see the reputation, throttling and banning section for details. the paymaster interface is as follows: function validatepaymasteruserop (useroperation calldata userop, bytes32 userophash, uint256 maxcost) external returns (bytes memory context, uint256 validationdata); function postop (postopmode mode, bytes calldata context, uint256 actualgascost) external; enum postopmode { opsucceeded, // user op succeeded opreverted, // user op reverted. still has to pay for gas. postopreverted // user op succeeded, but caused postop to revert } // add a paymaster stake (must be called by the paymaster) function addstake(uint32 _unstakedelaysec) external payable // unlock the stake (must wait unstakedelay before can withdraw) function unlockstake() external // withdraw the unlocked stake function withdrawstake(address payable withdrawaddress) external the paymaster must also have a deposit, which the entry point will charge useroperation costs from. the deposit (for paying gas fees) is separate from the stake (which is locked). the entry point must implement the following interface to allow paymasters (and optionally accounts) manage their deposit: // return the deposit of an account function balanceof(address account) public view returns (uint256) // add to the deposit of the given account function depositto(address account) public payable // withdraw from the deposit function withdrawto(address payable withdrawaddress, uint256 withdrawamount) external client behavior upon receiving a useroperation when a client receives a useroperation, it must first run some basic sanity checks, namely that: either the sender is an existing contract, or the initcode is not empty (but not both) if initcode is not empty, parse its first 20 bytes as a factory address. record whether the factory is staked, in case the later simulation indicates that it needs to be. if the factory accesses global state, it must be staked see reputation, throttling and banning section for details. the verificationgaslimit is sufficiently low (<= max_verification_gas) and the preverificationgas is sufficiently high (enough to pay for the calldata gas cost of serializing the useroperation plus pre_verification_overhead_gas) the paymasteranddata is either empty, or start with the paymaster address, which is a contract that (i) currently has nonempty code on chain, (ii) has a sufficient deposit to pay for the useroperation, and (iii) is not currently banned. during simulation, the paymaster’s stake is also checked, depending on its storage usage see reputation, throttling and banning section for details. the callgas is at least the cost of a call with non-zero value. the maxfeepergas and maxpriorityfeepergas are above a configurable minimum value that the client is willing to accept. at the minimum, they are sufficiently high to be included with the current block.basefee. the sender doesn’t have another useroperation already present in the pool (or it replaces an existing entry with the same sender and nonce, with a higher maxpriorityfeepergas and an equally increased maxfeepergas). only one useroperation per sender may be included in a single batch. a sender is exempt from this rule and may have multiple useroperations in the pool and in a batch if it is staked (see reputation, throttling and banning section below), but this exception is of limited use to normal accounts. if the useroperation object passes these sanity checks, the client must next run the first op simulation, and if the simulation succeeds, the client must add the op to the pool. a second simulation must also happen during bundling to make sure the useroperation is still valid. simulation simulation rationale in order to add a useroperation into the mempool (and later to add it into a bundle) we need to “simulate” its validation to make sure it is valid, and that it is capable of paying for its own execution. in addition, we need to verify that the same will hold true when executed on-chain. for this purpose, a useroperation is not allowed to access any information that might change between simulation and execution, such as current block time, number, hash etc. in addition, a useroperation is only allowed to access data related to this sender address: multiple useroperations should not access the same storage, so that it is impossible to invalidate a large number of useroperations with a single state change. there are 3 special contracts that interact with the account: the factory (initcode) that deploys the contract, the paymaster that can pay for the gas, and signature aggregator (described later) each of these contracts is also restricted in its storage access, to make sure useroperation validations are isolated. specification: to simulate a useroperation validation, the client makes a view call to simulatevalidation(userop) this method always revert with validationresult as successful response. if the call reverts with other error, the client rejects this userop. the simulated call performs the full validation, by calling: if initcode is present, create the account. account.validateuserop. if specified a paymaster: paymaster.validatepaymasteruserop. either validateuserop or validatepaymasteruserop may return a “validafter” and “validuntil” timestamps, which is the time-range that this useroperation is valid on-chain. the simulatevalidation call returns this range. a node may drop a useroperation if it expires too soon (e.g. wouldn’t make it to the next block) if the validationresult includes sigfail, the client should drop the useroperation. the operations differ in their opcode banning policy. in order to distinguish between them, there is a call to the number opcode (block.number), used as a delimiter between the 3 functions. while simulating userop validation, the client should make sure that: may not invokes any forbidden opcodes must not use gas opcode (unless followed immediately by one of { call, delegatecall, callcode, staticcall }.) storage access is limited as follows: self storage (of factory/paymaster, respectively) is allowed, but only if self entity is staked account storage access is allowed (see storage access by slots, below), in any case, may not use storage used by another userop sender in the same bundle (that is, paymaster and factory are not allowed as senders) limitation on “call” opcodes (call, delegatecall, callcode, staticcall): must not use value (except from account to the entrypoint) must not revert with out-of-gas destination address must have code (extcodesize>0) or be a standard ethereum precompile defined at addresses from 0x01 to 0x09 cannot call entrypoint’s methods, except depositto (to avoid recursion) extcodehash of every address accessed (by any opcode) does not change between first and second simulations of the op. extcodehash, extcodesize, extcodecopy may not access address with no code. if op.initcode.length != 0 , allow only one create2 opcode call (in the first (deployment) block), otherwise forbid create2. transient storage slots defined in eip-1153 and accessed using tload (0x5c) and tstore (0x5d) opcodes must follow the exact same validation rules as persistent storage if transient storage is enabled. storage associated with an address we define storage slots as “associated with an address” as all the slots that uniquely related on this address, and cannot be related with any other address. in solidity, this includes all storage of the contract itself, and any storage of other contracts that use this contract address as a mapping key. an address a is associated with: slots of contract a address itself. slot a on any other address. slots of type keccak256(a || x) + n on any other address. (to cover mapping(address => value), which is usually used for balance in erc-20 tokens). n is an offset value up to 128, to allow accessing fields in the format mapping(address => struct) alternative mempools the simulation rules above are strict and prevent the ability of paymasters and signature aggregators to grief the system. however, there might be use-cases where specific paymasters (and signature aggregators) can be validated (through manual auditing) and verified that they cannot cause any problem, while still require relaxing of the opcode rules. a bundler cannot simply “whitelist” request from a specific paymaster: if that paymaster is not accepted by all bundlers, then its support will be sporadic at best. instead, we introduce the term “alternate mempool”. useroperations that use whitelisted paymasters (or signature aggregators) are put into a separate mempool. only bundlers that support this whitelist will use useroperations from this mempool. these useroperations can be bundled together with useroperations from the main mempool bundling during bundling, the client should: exclude userops that access any sender address of another userop in the same batch. exclude userops that access any address created by another userop validation in the same batch (via a factory). for each paymaster used in the batch, keep track of the balance while adding userops. ensure that it has sufficient deposit to pay for all the userops that use it. sort userops by aggregator, to create the lists of userops-per-aggregator. for each aggregator, run the aggregator-specific code to create aggregated signature, and update the userops after creating the batch, before including the transaction in a block, the client should: run debug_tracecall with maximum possible gas, to enforce the validation opcode and precompile banning and storage access rules, as well as to verify the entire handleops batch transaction, and use the consumed gas for the actual transaction execution. if the call reverted, check the failedop event. a failedop during handleops simulation is an unexpected event since it was supposed to be caught by the single-useroperation simulation. if any verification context rule was violated the bundlers should treat it the same as if this useroperation reverted with a failedop event. remove the offending useroperation from the current bundle and from mempool. if the error is caused by a factory (error code is aa1x) or a paymaster (error code is aa3x), and the sender of the userop is not a staked entity, then issue a “ban” (see “reputation, throttling and banning”) for the guilty factory or paymaster. if the error is caused by a factory (error code is aa1x) or a paymaster (error code is aa3x), and the sender of the userop is a staked entity, do not ban the factory / paymaster from the mempool. instead, issue a “ban” for the staked sender entity. repeat until debug_tracecall succeeds. as staked entries may use some kind of transient storage to communicate data between useroperations in the same bundle, it is critical that the exact same opcode and precompile banning rules as well as storage access rules are enforced for the handleops validation in its entirety as for individual useroperations. otherwise, attackers may be able to use the banned opcodes to detect running on-chain and trigger a failedop revert. banning an offending entity for a given bundler is achieved by increasing its opsseen value by 1000000 and removing all useroperations for this entity already present in the mempool. this change will allow the negative reputation value to deteriorate over time consistent with other banning reasons. if any of the three conditions is violated, the client should reject the op. if both calls succeed (or, if op.paymaster == zero_address and the first call succeeds)without violating the three conditions, the client should accept the op. on a bundler node, the storage keys accessed by both calls must be saved as the accesslist of the useroperation when a bundler includes a bundle in a block it must ensure that earlier transactions in the block don’t make any useroperation fail. it should either use access lists to prevent conflicts, or place the bundle as the first transaction in the block. forbidden opcodes the forbidden opcodes are to be forbidden when depth > 2 (i.e. when it is the factory, account, paymaster, or other contracts called by them that are being executed). they are: gasprice, gaslimit, difficulty, timestamp, basefee, blockhash, number, selfbalance, balance, origin, gas, create, coinbase, selfdestruct. they should only be forbidden during verification, not execution. these opcodes are forbidden because their outputs may differ between simulation and execution, so simulation of calls using these opcodes does not reliably tell what would happen if these calls are later done on-chain. exceptions to the forbidden opcodes: a single create2 is allowed if op.initcode.length != 0 and must result in the deployment of a previously-undeployed useroperation.sender. gas is allowed if followed immediately by one of { call, delegatecall, callcode, staticcall }. (that is, making calls is allowed, using gasleft() or gas opcode directly is forbidden) reputation scoring and throttling/banning for global entities reputation rationale. useroperation’s storage access rules prevent them from interfere with each other. but “global” entities paymasters, factories and aggregators are accessed by multiple useroperations, and thus might invalidate multiple previously-valid useroperations. to prevent abuse, we throttle down (or completely ban for a period of time) an entity that causes invalidation of large number of useroperations in the mempool. to prevent such entities from “sybil-attack”, we require them to stake with the system, and thus make such dos attack very expensive. note that this stake is never slashed, and can be withdrawn any time (after unstake delay) unstaked entities are allowed, under the rules below. when staked, an entity is also allowed to use its own associated storage, in addition to sender’s associated storage. the stake value is not enforced on-chain, but specifically by each node while simulating a transaction. the stake is expected to be above min_stake_value, and unstake delay above min_unstake_delay the value of min_unstake_delay is 84600 (one day) the value of min_stake_value is determined per chain, and specified in the “bundler specification test suite” un-staked entities under the following special conditions, unstaked entities still can be used: an entity that doesn’t use any storage at all, or only the senders’s storage (not the entity’s storage that does require a stake) if the userop doesn’t create a new account (that is initcode is empty), or the userop creates a new account using a staked factory contract, then the entity may also use storage associated with the sender) a paymaster that has a “postop()” method (that is, validatepaymasteruserop returns “context”) must be staked specification. in the following specification, “entity” is either address that is explicitly referenced by the useroperation: sender, factory, paymaster and aggregator. clients maintain two mappings with a value for staked entities: opsseen: map[address, int] opsincluded: map[address, int] if an entity doesn’t use storage at all, or only reference storage associated with the “sender” (see storage associated with an address), then it is considered “ok”, without using the rules below. when the client learns of a new staked entity, it sets opsseen[entity] = 0 and opsincluded[entity] = 0 . the client sets opsseen[entity] +=1 each time it adds an op with that entity to the useroperationpool, and the client sets opsincluded[entity] += 1 each time an op that was in the useroperationpool is included on-chain. every hour, the client sets opsseen[entity] -= opsseen[entity] // 24 and opsincluded[entity] -= opsincluded[entity] // 24 for all entities (so both values are 24-hour exponential moving averages). we define the status of an entity as follows: ok, throttled, banned = 0, 1, 2 def status(paymaster: address, opsseen: map[address, int], opsincluded: map[address, int]): if paymaster not in opsseen: return ok min_expected_included = opsseen[paymaster] // min_inclusion_rate_denominator if min_expected_included <= opsincluded[paymaster] + throttling_slack: return ok elif min_expected_included <= opsincluded[paymaster] + ban_slack: return throttled else: return banned stated in simpler terms, we expect at least 1 / min_inclusion_rate_denominator of all ops seen on the network to get included. if an entity falls too far behind this minimum, it gets throttled (meaning, the client does not accept ops from that paymaster if there is already an op with that entity, and an op only stays in the pool for 10 blocks), if the entity falls even further behind, it gets banned. throttling and banning naturally decay over time because of the exponential-moving-average rule. non-bundling clients and bundlers should use different settings for the above params: param client setting bundler setting min_inclusion_rate_denominator 100 10 throttling_slack 10 10 ban_slack 50 50 to help make sense of these params, note that a malicious paymaster can at most cause the network (only the p2p network, not the blockchain) to process ban_slack * min_inclusion_rate_denominator / 24 non-paying ops per hour. rationale the main challenge with a purely smart contract wallet based account abstraction system is dos safety: how can a block builder including an operation make sure that it will actually pay fees, without having to first execute the entire operation? requiring the block builder to execute the entire operation opens a dos attack vector, as an attacker could easily send many operations that pretend to pay a fee but then revert at the last moment after a long execution. similarly, to prevent attackers from cheaply clogging the mempool, nodes in the p2p network need to check if an operation will pay a fee before they are willing to forward it. in this proposal, we expect accounts to have a validateuserop method that takes as input a useroperation, and verify the signature and pay the fee. this method is required to be almost-pure: it is only allowed to access the storage of the account itself, cannot use environment opcodes (eg. timestamp), and can only edit the storage of the account, and can also send out eth (needed to pay the entry point). the method is gas-limited by the verificationgaslimit of the useroperation; nodes can choose to reject operations whose verificationgaslimit is too high. these restrictions allow block builders and network nodes to simulate the verification step locally, and be confident that the result will match the result when the operation actually gets included into a block. the entry point-based approach allows for a clean separation between verification and execution, and keeps accounts’ logic simple. the alternative would be to require accounts to follow a template where they first self-call to verify and then self-call to execute (so that the execution is sandboxed and cannot cause the fee payment to revert); template-based approaches were rejected due to being harder to implement, as existing code compilation and verification tooling is not designed around template verification. paymasters paymasters facilitate transaction sponsorship, allowing third-party-designed mechanisms to pay for transactions. many of these mechanisms could be done by having the paymaster wrap a useroperation with their own, but there are some important fundamental limitations to that approach: no possibility for “passive” paymasters (eg. that accept fees in some erc-20 token at an exchange rate pulled from an on-chain dex) paymasters run the risk of getting griefed, as users could send ops that appear to pay the paymaster but then change their behavior after a block the paymaster scheme allows a contract to passively pay on users’ behalf under arbitrary conditions. it even allows erc-20 token paymasters to secure a guarantee that they would only need to pay if the user pays them: the paymaster contract can check that there is sufficient approved erc-20 balance in the validatepaymasteruserop method, and then extract it with transferfrom in the postop call; if the op itself transfers out or de-approves too much of the erc-20s, the inner postop will fail and revert the execution and the outer postop can extract payment (note that because of storage access restrictions the erc-20 would need to be a wrapper defined within the paymaster itself). first-time account creation it is an important design goal of this proposal to replicate the key property of eoas that users do not need to perform some custom action or rely on an existing user to create their wallet; they can simply generate an address locally and immediately start accepting funds. the wallet creation itself is done by a “factory” contract, with wallet-specific data. the factory is expected to use create2 (not create) to create the wallet, so that the order of creation of wallets doesn’t interfere with the generated addresses. the initcode field (if non-zero length) is parsed as a 20-byte address, followed by “calldata” to pass to this address. this method call is expected to create a wallet and return its address. if the factory does use create2 or some other deterministic method to create the wallet, it’s expected to return the wallet address even if the wallet has already been created. this is to make it easier for clients to query the address without knowing if the wallet has already been deployed, by simulating a call to entrypoint.getsenderaddress(), which calls the factory under the hood. when initcode is specified, if either the sender address points to an existing contract, or (after calling the initcode) the sender address still does not exist, then the operation is aborted. the initcode must not be called directly from the entrypoint, but from another address. the contract created by this factory method should accept a call to validateuserop to validate the userop’s signature. for security reasons, it is important that the generated contract address will depend on the initial signature. this way, even if someone can create a wallet at that address, he can’t set different credentials to control it. the factory has to be staked if it accesses global storage see reputation, throttling and banning section for details. note: in order for the wallet to determine the “counterfactual” address of the wallet (prior its creation), it should make a static call to the entrypoint.getsenderaddress() entry point upgrading accounts are encouraged to be delegatecall forwarding contracts for gas efficiency and to allow account upgradability. the account code is expected to hard-code the entry point into their code for gas efficiency. if a new entry point is introduced, whether to add new functionality, improve gas efficiency, or fix a critical security bug, users can self-call to replace their account’s code address with a new code address containing code that points to a new entry point. during an upgrade process, it’s expected that two mempools will run in parallel. rpc methods (eth namespace) * eth_senduseroperation eth_senduseroperation submits a user operation object to the user operation pool of the client. the client must validate the useroperation, and return a result accordingly. the result should be set to the userophash if and only if the request passed simulation and was accepted in the client’s user operation pool. if the validation, simulation, or user operation pool inclusion fails, result should not be returned. rather, the client should return the failure reason. parameters: useroperation a full user-operation struct. all fields must be set as hex values. empty bytes block (e.g. empty initcode) must be set to "0x" entrypoint the entrypoint address the request should be sent through. this must be one of the entry points returned by the supportedentrypoints rpc call. return value: if the useroperation is valid, the client must return the calculated userophash for it in case of failure, must return an error result object, with code and message. the error code and message should be set as follows: code: -32602 invalid useroperation struct/fields code: -32500 transaction rejected by entrypoint’s simulatevalidation, during wallet creation or validation the message field must be set to the failedop’s “aaxx” error message from the entrypoint code: -32501 transaction rejected by paymaster’s validatepaymasteruserop the message field should be set to the revert message from the paymaster the data field must contain a paymaster value code: -32502 transaction rejected because of opcode validation code: -32503 useroperation out of time-range: either wallet or paymaster returned a time-range, and it is already expired (or will expire soon) the data field should contain the validuntil and validafter values the data field should contain a paymaster value, if this error was triggered by the paymaster code: -32504 transaction rejected because paymaster (or signature aggregator) is throttled/banned the data field should contain a paymaster or aggregator value, depending on the failed entity code: -32505 transaction rejected because paymaster (or signature aggregator) stake or unstake-delay is too low the data field should contain a paymaster or aggregator value, depending on the failed entity the data field should contain a minimumstake and minimumunstakedelay code: -32506 transaction rejected because wallet specified unsupported signature aggregator the data field should contain an aggregator value code: -32507 transaction rejected because of wallet signature check failed (or paymaster signature, if the paymaster uses its data as signature) example: request: { "jsonrpc": "2.0", "id": 1, "method": "eth_senduseroperation", "params": [ { sender, // address nonce, // uint256 initcode, // bytes calldata, // bytes callgaslimit, // uint256 verificationgaslimit, // uint256 preverificationgas, // uint256 maxfeepergas, // uint256 maxpriorityfeepergas, // uint256 paymasteranddata, // bytes signature // bytes }, entrypoint // address ] } response: { "jsonrpc": "2.0", "id": 1, "result": "0x1234...5678" } example failure responses: { "jsonrpc": "2.0", "id": 1, "error": { "message": "aa21 didn't pay prefund", "code": -32500 } } { "jsonrpc": "2.0", "id": 1, "error": { "message": "paymaster stake too low", "data": { "paymaster": "0x123456789012345678901234567890123456790", "minimumstake": "0xde0b6b3a7640000", "minimumunstakedelay": "0x15180" }, "code": -32504 } } * eth_estimateuseroperationgas estimate the gas values for a useroperation. given useroperation optionally without gas limits and gas prices, return the needed gas limits. the signature field is ignored by the wallet, so that the operation will not require user’s approval. still, it might require putting a “semi-valid” signature (e.g. a signature in the right length) parameters: same as eth_senduseroperation gas limits (and prices) parameters are optional, but are used if specified. maxfeepergas and maxpriorityfeepergas default to zero, so no payment is required by neither account nor paymaster. return values: preverificationgas gas overhead of this useroperation verificationgaslimit actual gas used by the validation of this useroperation callgaslimit value used by inner account execution error codes: same as eth_senduseroperation this operation may also return an error if the inner call to the account contract reverts. * eth_getuseroperationbyhash return a useroperation based on a hash (userophash) returned by eth_senduseroperation parameters hash a userophash value returned by eth_senduseroperation return value: null in case the useroperation is not yet included in a block, or a full useroperation, with the addition of entrypoint, blocknumber, blockhash and transactionhash * eth_getuseroperationreceipt return a useroperation receipt based on a hash (userophash) returned by eth_senduseroperation parameters hash a userophash value returned by eth_senduseroperation return value: null in case the useroperation is not yet included in a block, or: userophash the request hash entrypoint sender nonce paymaster the paymaster used for this userop (or empty) actualgascost actual amount paid (by account or paymaster) for this useroperation actualgasused total gas used by this useroperation (including preverification, creation, validation and execution) success boolean did this execution completed without revert reason in case of revert, this is the revert reason logs the logs generated by this useroperation (not including logs of other useroperations in the same bundle) receipt the transactionreceipt object. note that the returned transactionreceipt is for the entire bundle, not only for this useroperation. * eth_supportedentrypoints returns an array of the entrypoint addresses supported by the client. the first element of the array should be the entrypoint addressed preferred by the client. # request { "jsonrpc": "2.0", "id": 1, "method": "eth_supportedentrypoints", "params": [] } # response { "jsonrpc": "2.0", "id": 1, "result": [ "0xcd01c8aa8995a59eb7b2627e69b40e0524b5ecf8", "0x7a0a0d159218e6a2f407b99173a2b12a6ddfc2a6" ] } * eth_chainid returns eip-155 chain id. # request { "jsonrpc": "2.0", "id": 1, "method": "eth_chainid", "params": [] } # response { "jsonrpc": "2.0", "id": 1, "result": "0x1" } rpc methods (debug namespace) this api must only be available on testing mode and is required by the compatibility test suite. in production, any debug_* rpc calls should be blocked. * debug_bundler_clearstate clears the bundler mempool and reputation data of paymasters/accounts/factories/aggregators. # request { "jsonrpc": "2.0", "id": 1, "method": "debug_bundler_clearstate", "params": [] } # response { "jsonrpc": "2.0", "id": 1, "result": "ok" } * debug_bundler_dumpmempool dumps the current useroperations mempool parameters: entrypoint the entrypoint used by eth_senduseroperation returns: array array of useroperations currently in the mempool. # request { "jsonrpc": "2.0", "id": 1, "method": "debug_bundler_dumpmempool", "params": ["0x1306b01bc3e4ad202612d3843387e94737673f53"] } # response { "jsonrpc": "2.0", "id": 1, "result": [ { sender, // address nonce, // uint256 initcode, // bytes calldata, // bytes callgaslimit, // uint256 verificationgaslimit, // uint256 preverificationgas, // uint256 maxfeepergas, // uint256 maxpriorityfeepergas, // uint256 paymasteranddata, // bytes signature // bytes } ] } * debug_bundler_sendbundlenow forces the bundler to build and execute a bundle from the mempool as handleops() transaction. returns: transactionhash # request { "jsonrpc": "2.0", "id": 1, "method": "debug_bundler_sendbundlenow", "params": [] } # response { "jsonrpc": "2.0", "id": 1, "result": "0xdead9e43632ac70c46b4003434058b18db0ad809617bd29f3448d46ca9085576" } * debug_bundler_setbundlingmode sets bundling mode. after setting mode to “manual”, an explicit call to debug_bundler_sendbundlenow is required to send a bundle. parameters: mode ‘manual’ ‘auto’ # request { "jsonrpc": "2.0", "id": 1, "method": "debug_bundler_setbundlingmode", "params": ["manual"] } # response { "jsonrpc": "2.0", "id": 1, "result": "ok" } * debug_bundler_setreputation sets reputation of given addresses. parameters: parameters: an array of reputation entries to add/replace, with the fields: address the address to set the reputation for. opsseen number of times a user operations with that entity was seen and added to the mempool opsincluded number of times a user operations that uses this entity was included on-chain status (string) the status of the address in the bundler ‘ok’ ‘throttled’ ‘banned’. entrypoint the entrypoint used by eth_senduseroperation # request { "jsonrpc": "2.0", "id": 1, "method": "debug_bundler_setreputation", "params": [ [ { "address": "0x7a0a0d159218e6a2f407b99173a2b12a6ddfc2a6", "opsseen": 20, "opsincluded": 13 } ], "0x1306b01bc3e4ad202612d3843387e94737673f53" ] } # response { "jsonrpc": "2.0", "id": 1, "result": "ok" } * debug_bundler_dumpreputation returns the reputation data of all observed addresses. returns an array of reputation objects, each with the fields described above in debug_bundler_setreputation with the parameters: entrypoint the entrypoint used by eth_senduseroperation return value: an array of reputation entries with the fields: address the address to set the reputation for. opsseen number of times a user operations with that entity was seen and added to the mempool opsincluded number of times a user operations that uses this entity was included on-chain status (string) the status of the address in the bundler ‘ok’ ‘throttled’ ‘banned’. # request { "jsonrpc": "2.0", "id": 1, "method": "debug_bundler_dumpreputation", "params": ["0x1306b01bc3e4ad202612d3843387e94737673f53"] } # response { "jsonrpc": "2.0", "id": 1, "result": [ { "address": "0x7a0a0d159218e6a2f407b99173a2b12a6ddfc2a6", "opsseen": 20, "opsincluded": 19, "status": "ok" } ] } backwards compatibility this eip does not change the consensus layer, so there are no backwards compatibility issues for ethereum as a whole. unfortunately it is not easily compatible with pre-erc-4337 accounts, because those accounts do not have a validateuserop function. if the account has a function for authorizing a trusted op submitter, then this could be fixed by creating an erc-4337 compatible account that re-implements the verification logic as a wrapper and setting it to be the original account’s trusted op submitter. reference implementation see https://github.com/eth-infinitism/account-abstraction/tree/main/contracts security considerations the entry point contract will need to be very heavily audited and formally verified, because it will serve as a central trust point for all erc-4337. in total, this architecture reduces auditing and formal verification load for the ecosystem, because the amount of work that individual accounts have to do becomes much smaller (they need only verify the validateuserop function and its “check signature, increment nonce and pay fees” logic) and check that other functions are msg.sender == entry_point gated (perhaps also allowing msg.sender == self), but it is nevertheless the case that this is done precisely by concentrating security risk in the entry point contract that needs to be verified to be very robust. verification would need to cover two primary claims (not including claims needed to protect paymasters, and claims needed to establish p2p-level dos resistance): safety against arbitrary hijacking: the entry point only calls an account generically if validateuserop to that specific account has passed (and with op.calldata equal to the generic call’s calldata) safety against fee draining: if the entry point calls validateuserop and passes, it also must make the generic call with calldata equal to op.calldata copyright copyright and related rights waived via cc0. citation please cite this document as: vitalik buterin (@vbuterin), yoav weiss (@yoavw), dror tirosh (@drortirosh), shahaf nacson (@shahafn), alex forshtat (@forshtat), kristof gazso (@kristofgazso), tjaden hess (@tjade273), "erc-4337: account abstraction using alt mempool [draft]," ethereum improvement proposals, no. 4337, september 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4337. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7507: multi-user nft extension ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7507: multi-user nft extension an extension of erc-721 to allow multiple users to a token with restricted permissions. authors ming jiang (@minkyn), zheng han (@hanbsd), fan yang (@fayang) created 2023-08-24 discussion link https://ethereum-magicians.org/t/eip-7507-multi-user-nft-extension/15660 requires eip-721 table of contents abstract motivation specification rationale backwards compatibility test cases reference implementation security considerations copyright abstract this standard is an extension of erc-721. it proposes a new role user in addition to owner for a token. a token can have multiple users under separate expiration time. it allows the subscription model where an nft can be subscribed non-exclusively by different users. motivation some nfts represent ip assets, and ip assets have the need to be licensed for access without transferring ownership. the subscription model is a very common practice for ip licensing where multiple users can subscribe to an nft to obtain access. each subscription is usually time limited and will thus be recorded with an expiration time. existing erc-4907 introduces a similar feature, but does not allow for more than one user. it is more suitable in the rental scenario where a user gains an exclusive right of use to an nft before the next user. this rental model is common for nfts representing physical assets like in games, but not very useful for shareable ip assets. specification solidity interface available at ierc7507.sol: interface ierc7507 { /// @notice emitted when the expires of a user for an nft is changed event updateuser(uint256 indexed tokenid, address indexed user, uint64 expires); /// @notice get the user expires of an nft /// @param tokenid the nft to get the user expires for /// @param user the user to get the expires for /// @return the user expires for this nft function userexpires(uint256 tokenid, address user) external view returns(uint256); /// @notice set the user expires of an nft /// @param tokenid the nft to set the user expires for /// @param user the user to set the expires for /// @param expires the user could use the nft before expires in unix timestamp function setuser(uint256 tokenid, address user, uint64 expires) external; } rationale this standard complements erc-4907 to support multi-user feature. therefore the proposed interface tries to keep consistent using the same naming for functions and parameters. however, we didn’t include the corresponding usersof(uint256 tokenid) function as that would imply the implemention has to support enumerability over multiple users. it is not always necessary, for example, in the case of open subscription. so we decide not to add it to the interface and leave the choice up to the implementers. backwards compatibility no backwards compatibility issues found. test cases test cases available available at: erc7507.test.ts: import { loadfixture } from "@nomicfoundation/hardhat-toolbox/network-helpers"; import { expect } from "chai"; import { ethers } from "hardhat"; const name = "name"; const symbol = "symbol"; const token_id = 1234; const expiration = 2000000000; const year = 31536000; describe("erc7507", function () { async function deploycontractfixture() { const [deployer, owner, user1, user2] = await ethers.getsigners(); const contract = await ethers.deploycontract("erc7507", [name, symbol], deployer); await contract.mint(owner, token_id); return { contract, owner, user1, user2 }; } describe("functions", function () { it("should not set user if not owner or approved", async function () { const { contract, user1 } = await loadfixture(deploycontractfixture); await expect(contract.setuser(token_id, user1, expiration)) .to.be.revertedwith("erc7507: caller is not owner or approved"); }); it("should return zero expiration for nonexistent user", async function () { const { contract, user1 } = await loadfixture(deploycontractfixture); expect(await contract.userexpires(token_id, user1)).to.equal(0); }); it("should set users and then update", async function () { const { contract, owner, user1, user2 } = await loadfixture(deploycontractfixture); await contract.connect(owner).setuser(token_id, user1, expiration); await contract.connect(owner).setuser(token_id, user2, expiration); expect(await contract.userexpires(token_id, user1)).to.equal(expiration); expect(await contract.userexpires(token_id, user2)).to.equal(expiration); await contract.connect(owner).setuser(token_id, user1, expiration + year); await contract.connect(owner).setuser(token_id, user2, 0); expect(await contract.userexpires(token_id, user1)).to.equal(expiration + year); expect(await contract.userexpires(token_id, user2)).to.equal(0); }); }); describe("events", function () { it("should emit event when set user", async function () { const { contract, owner, user1 } = await loadfixture(deploycontractfixture); await expect(contract.connect(owner).setuser(token_id, user1, expiration)) .to.emit(contract, "updateuser").withargs(token_id, user1.address, expiration); }); }); }); reference implementation reference implementation available at: erc7507.sol: // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/erc721/erc721.sol"; import "./ierc7507.sol"; contract erc7507 is erc721, ierc7507 { mapping(uint256 => mapping(address => uint64)) private _expires; constructor( string memory name, string memory symbol ) erc721(name, symbol) {} function supportsinterface( bytes4 interfaceid ) public view virtual override returns (bool) { return interfaceid == type(ierc7507).interfaceid || super.supportsinterface(interfaceid); } function userexpires( uint256 tokenid, address user ) public view virtual override returns(uint256) { require(_exists(tokenid), "erc7507: query for nonexistent token"); return _expires[tokenid][user]; } function setuser( uint256 tokenid, address user, uint64 expires ) public virtual override { require(_isapprovedorowner(_msgsender(), tokenid), "erc7507: caller is not owner or approved"); _expires[tokenid][user] = expires; emit updateuser(tokenid, user, expires); } } security considerations no security considerations found. copyright copyright and related rights waived via cc0. citation please cite this document as: ming jiang (@minkyn), zheng han (@hanbsd), fan yang (@fayang), "erc-7507: multi-user nft extension [draft]," ethereum improvement proposals, no. 7507, august 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7507. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6780: selfdestruct only in same transaction ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: core eip-6780: selfdestruct only in same transaction selfdestruct will recover all funds to the target but not delete the account, except when called in the same transaction as creation authors guillaume ballet (@gballet), vitalik buterin (@vbuterin), dankrad feist (@dankrad) created 2023-03-25 last call deadline 2024-02-15 requires eip-2681, eip-2929, eip-3529 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip changes the functionality of the selfdestruct opcode. the new functionality will be only to send all ether in the account to the target, except that the current behaviour is preserved when selfdestruct is called in the same transaction a contract was created. motivation the selfdestruct opcode requires large changes to the state of an account, in particular removing all code and storage. this will not be possible in the future with verkle trees: each account will be stored in many different account keys, which will not be obviously connected to the root account. this eip implements this change. applications that only use selfdestruct to retrieve funds will still work. applications that only use selfdestruct in the same transaction as they created a contract will also continue to work without any changes. specification the behaviour of selfdestruct is changed in the following way: when selfdestruct is executed in a transaction that is not the same as the contract calling selfdestruct was created: the current execution frame halts. selfdestruct does not delete any data (including storage keys, code, or the account itself). selfdestruct transfers the entire account balance to the target. note that if the target is the same as the contract calling selfdestruct there is no net change in balances. unlike the prior specification, ether will not be burnt in this case. note that no refund is given since eip-3529. note that the rules of eip-2929 regarding selfdestruct remain unchanged. when selfdestruct is executed in the same transaction as the contract was created: selfdestruct continues to behave as it did prior to this eip, this includes the following actions the current execution frame halts. selfdestruct deletes data as previously specified. selfdestruct transfers the entire account balance to the target the account balance of the contact calling selfdestruct is set to 0. note that if the target is the same as the contract calling selfdestruct that ether will be burnt. note that no refund is given since eip-3529. note that the rules of eip-2929 regarding selfdestruct remain unchanged. a contract is considered created at the beginning of a create transaction or when a create series operation begins execution (create, create2, and other operations that deploy contracts in the future). if a balance exists at the contract’s new address it is still considered to be a contract creation. the selfdestruct opcode remains deprecated as specified in eip-6049. any use in newly deployed contracts is strongly discouraged even if this new behaviour is taken into account, and future changes to the evm might further reduce the functionality of the opcode. rationale getting rid of the selfdestruct opcode has been considered in the past, and there are currently no strong reasons to use it. this eip implements a behavior that will attempt to leave some common uses of selfdestruct working, while reducing the complexity of the change on evm implementations that would come from contract versioning. handling the account creation and contract creation as two distinct and possibly separate events is needed for use cases such as counterfactual accounts. by allowing the selfdestruct to delete the account at contract creation time it will not result in stubs of counterfactually instantiated contracts that never had any on-chain state other than a balance prior to the contract creation. these accounts would never have any storage and thus the trie updates to delete the account would be limited to the account node, which is the same impact a regular transfer of ether would have. backwards compatibility this eip requires a hard fork, since it modifies consensus rules. contracts that depended on re-deploying contracts at the same address using create2 (after a selfdestruct) will no longer function properly if the created contract does not call selfdestruct within the same transaction. previously it was possible to burn ether by calling selfdestruct targeting the executing contract as the beneficiary. if the contract existed prior to the transaction the ether will not be burned. if the contract was newly created in the transaction the ether will be burned, as before. security considerations the following applications of selfdestruct will be broken and applications that use it in this way are not safe anymore: where create2 is used to redeploy a contract in the same place in order to make a contract upgradable. this is not supported anymore and erc-2535 or other types of proxy contracts should be used instead. where a contract depended on burning ether via a selfdestruct with the contract as beneficiary, in a contract not created within the same transaction. copyright copyright and related rights waived via cc0. citation please cite this document as: guillaume ballet (@gballet), vitalik buterin (@vbuterin), dankrad feist (@dankrad), "eip-6780: selfdestruct only in same transaction [draft]," ethereum improvement proposals, no. 6780, march 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6780. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1577: contenthash field for ens ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1577: contenthash field for ens authors dean eigenmann , nick johnson created 2018-11-13 table of contents abstract motivation specification example swarm fallback implementation copyright abstract this eip introduces the new contenthash field for ens resolvers, allowing for a better defined system of mapping names to network and content addresses. additionally the content and multihash fields are deprecated. motivation multiple applications including metamask and mobile clients such as status have begun resolving ens names to content hosted on distributed systems such as ipfs and swarm. due to the various ways content can be stored and addressed, a standard is required so these applications know how to resolve names and that domain owners know how their content will be resolved. the contenthash field allows for easy specification of network and content addresses in ens. specification the field contenthash is introduced, which permits a wide range of protocols to be supported by ens names. resolvers supporting this field must return true when the supportsinterface function is called with argument 0xbc1c58d1. the fields content and multihash are deprecated. the value returned by contenthash must be represented as a machine-readable multicodec. the format is specified as follows: protocodes and their meanings are specified in the multiformats/multicodec repository. the encoding of the value depends on the content type specified by the protocode. values with protocodes of 0xe3 and 0xe4 represent ipfs and swarm content; these values are encoded as v1 cids without a base prefix, meaning their value is formatted as follows:

when resolving a contenthash, applications must use the protocol code to determine what type of address is encoded, and resolve the address appropriately for that protocol, if supported. example ipfs input data: storage system: ipfs (0xe3) cid version: 1 (0x01) content type: dag-pb (0x70) hash function: sha2-256 (0x12) hash length: 32 bytes (0x20) hash: 29f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f binary format: 0xe3010170122029f2d17be6139079dc48696d1f582a8530eb9805b561eda517e22a892c7e3f1f text format: ipfs://qmraqb6yacyidp37uddnjfy5vquibrcqdyow1cudgwxkd4 swarm input data: storage system: swarm (0xe4) cid version: 1 (0x01) content type: swarm-manifest (0xfa) hash function: keccak256 (0x1b) hash length: 32 bytes (0x20) hash: d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 binary format: 0xe40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 text format: bzz://d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 example usage with swarm hash: $ swarm hash ens contenthash d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 > e40101fa011b20d1de9994b4d039f6548d191eb26786769f580809256b4685ef316805265ea162 fallback in order to support names that have an ipfs or swarm hash in their content field, a grace period must be implemented offering those name holders time to update their names. if a resolver does not support the multihash interface, it must be checked whether they support the content interface. if they do, the value of that field should be treated in a context dependent fashion and resolved. this condition must be enforced until at least march 31st, 2019. implementation to support contenthash, a new resolver has been developed and can be found here, you can also find this smart contract deployed on: mainnet : 0xd3ddccdd3b25a8a7423b5bee360a42146eb4baf3 ropsten : 0xde469c7106a9fbc3fb98912bb00be983a89bddca there are also implementations in multiple languages to encode and decode contenthash: javascript python copyright copyright and related rights waived via cc0. citation please cite this document as: dean eigenmann , nick johnson , "erc-1577: contenthash field for ens [draft]," ethereum improvement proposals, no. 1577, november 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1577. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. security alert – [implementation bug in go clients causing increase in difficulty – fixed – miners check and update go clients] | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search security alert – [implementation bug in go clients causing increase in difficulty – fixed – miners check and update go clients] posted by jutta steiner on september 3, 2015 security implementation bug in the go client leads to steady increase of difficulty independent of hashing power. affected configurations: all go client versions v1.0.x, v1.1.x, release and develop branches. the bug was introduced in a recent update and release through commit https://github.com/ethereum/go-ethereum/commit/7324176f702a77fc331bf16a968d2eb4bccce021 which went into the affected client versions. all miners running earlier mentioned versions are affected and are advised to update as soon as possible. likelihood: high severity: medium impact: increase in block time will lead to an exponential increase in difficulty details: a bug in the go client leads to steady increase in difficulty in the following block, as timestamp in new block = timestamp + 1 of old block, regardless of the actual time, when mining. this leads to an increase in the difficulty independently of the hashing power effects on expected chain reorganisation depth: none proposed temporary workaround: none remedial action taken by ethereum: provision of hotfixes as below: if using the ppa: sudo apt-get update then sudo apt-get upgrade if using brew: brew update then brew reinstall ethereum if using a windows binary: download the updated binary from the release page if you are building from source: git pull followed by make geth (please use the master branch 587669215b878566c4a7b91fbf88a6fd2ec4f46a) previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-7015: nft creator attribution ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7015: nft creator attribution extending nfts with cryptographically secured creator attribution. authors carlos flores (@strollinghome) created 2023-05-11 discussion link https://ethereum-magicians.org/t/eip-authorship-attribution-for-erc721/14244 requires eip-55, eip-155, eip-712, eip-721, eip-1155 table of contents abstract motivation specification reference implementation rationale backwards compatibility security considerations copyright abstract this ethereum improvement proposal aims to solve the issue of creator attribution for non-fungible token (nft) standards (erc-721, erc-1155). to achieve this, this eip proposes a mechanism where the nft creator signs the required parameters for the nft creation, including the nft metadata in a hash along with any other relevant information. the signed parameters and the signature are then validated and emitted during the deployment transaction, which allows the nft to validate the creator and nft platforms to attribute creatorship correctly. this method ensures that even if a different wallet sends the deployment transaction, the correct account is attributed as the creator. motivation current nft platforms assume that the wallet deploying the smart contract is the creator of the nft, leading to a misattribution in cases where a different wallet sends the deployment transaction. this happens often when working with smart wallet accounts, and new contract deployment strategies such as the first collector deploying the nft contract. this proposal aims to solve the problem by allowing creators to sign the parameters required for nft creation so that any wallet can send the deployment transaction with an signal in a verifiable way who is the creator. specification the keywords “must,” “must not,” “required,” “shall,” “shall not,” “should,” “should not,” “recommended,” “may,” and “optional” in this document are to be interpreted as described in rfc 2119. erc-721 and erc-1155 compliant contracts may implement this nft creator attribution extension to provide a standard event to be emitted that defines the nft creator at the time of contract creation. this eip takes advantage of the fact that contract addresses can be precomputed before a contract is deployed. whether the nft contract is deployed through another contract (a factory) or through an eoa, the creator can be correctly attributed using this specification. signing mechanism creator consent is given by signing an eip-712 compatible message; all signatures compliant with this eip must include all fields defined. the struct signed can be any arbitrary data that defines how to create the token; it must hashed in an eip-712 compatible format with a proper eip-712 domain. the following shows some examples of structs that could be encoded into structhash (defined below): // example struct that can be encoded in `structhash`; defines that a token can be created with a metadatauri and price: struct tokencreation { string metadatauri; uint256 price; uint256 nonce; } signature validation creator attribution is given through a signature verification that must be verified by the nft contract being deployed and an event that must be emitted by the nft contract during the deployment transaction. the event includes all the necessary fields for reconstructing the signed digest and validating the signature to ensure it matches the specified creator. the event name is creatorattribution and includes the following fields: structhash: hashed information for deploying the nft contract (e.g. name, symbol, admins etc). this corresponds to the value hashstruct as defined in the eip-712 definition of hashstruct standard. domainname: the domain name of the contract verifying the singature (for eip-712 signature validation). version: the version of the contract verifying the signature (for eip-712 signature validation) creator: the creator’s account signature: the creator’s signature the event is defined as follows: event creatorattribution( bytes32 structhash, string domainname, string version, address creator, bytes signature ); note that although the chainid parameters is necessary for eip-712 signatures, we omit the parameter from the event as it can be inferred through the transaction data. similarly, the verifyingcontract parameter for signature verification is omitted since it must be the same as the emitter field in the transaction. emitter must be the token. a platform can verify the validity of the creator attribution by reconstructing the signature digest with the parameters emitted and recovering the signer from the signature parameter. the recovered signer must match the creator emitted in the event. if creatorattribution event is present creator and the signature is validated correctly, attribution must be given to the creator instead of the account that submitted the transaction. reference implementation example signature validator pragma solidity 0.8.20; import "@openzeppelin/contracts/utils/cryptography/eip712.sol"; import "@openzeppelin/contracts/utils/cryptography/ecdsa.sol"; import "@openzeppelin/contracts/interfaces/ierc1271.sol"; abstract contract erc7015 is eip712 { error invalid_signature(); event creatorattribution( bytes32 structhash, string domainname, string version, address creator, bytes signature ); /// @notice define magic value to verify smart contract signatures (erc1271). bytes4 internal constant magic_value = bytes4(keccak256("isvalidsignature(bytes32,bytes)")); function _validatesignature( bytes32 structhash, address creator, bytes memory signature ) internal { if (!_isvalid(structhash, creator, signature)) revert invalid_signature(); emit creatorattribution(structhash, "erc7015", "1", creator, signature); } function _isvalid( bytes32 structhash, address signer, bytes memory signature ) internal view returns (bool) { require(signer != address(0), "cannot validate"); bytes32 digest = _hashtypeddatav4(structhash); // if smart contract is the signer, verify using erc-1271 smart-contract /// signature verification method if (signer.code.length != 0) { try ierc1271(signer).isvalidsignature(digest, signature) returns ( bytes4 magicvalue ) { return magic_value == magicvalue; } catch { return false; } } // otherwise, recover signer and validate that it matches the expected // signer address recoveredsigner = ecdsa.recover(digest, signature); return recoveredsigner == signer; } } rationale by standardizing the creatorattribution event, this eip enables platforms to ascertain creator attribution without relying on implicit assumptions. establishing a standard for creator attribution empowers platforms to manage the complex aspects of deploying contracts while preserving accurate onchain creator information. this approach ensures a more reliable and transparent method for identifying nft creators, fostering trust among participants in the nft ecosystem. erc-5375 attempts to solve the same issue and although offchain data offers improved backward compatibility, ensuring accurate and immutable creator attribution is vital for nfts. a standardized onchain method for creator attribution is inherently more reliable and secure. in contrast to this proposal, erc-5375 does not facilitate specifying creators for all tokens within an nft collection, which is a prevalent practice, particularly in emerging use cases. both this proposal and erc-5375 share similar limitations regarding address-based creator attribution: the standard defines a protocol to verify that a certain address provided consent. however, it does not guarantee that the address corresponds to the expected creator […]. proving a link between an address and the entity behind it is beyond the scope of this document. backwards compatibility since the standard requires an event to be emitted during the nfts deployment transaction, existing nfts cannot implement this standard. security considerations a potential attack exploiting this proposal could involve deceiving creators into signing creator attribution consent messages unintentionally. consequently, creators must ensure that all signature fields correspond to the necessary ones before signing. copyright copyright and related rights waived via cc0. citation please cite this document as: carlos flores (@strollinghome), "erc-7015: nft creator attribution [draft]," ethereum improvement proposals, no. 7015, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7015. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5018: filesystem-like interface for contracts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5018: filesystem-like interface for contracts an interface to provide access to binary objects similar to filesystems. authors qi zhou (@qizhou) created 2022-04-18 discussion link https://ethereum-magicians.org/t/eip-5018-directory-standard/8958 table of contents abstract motivation specification directory rationale interactions between unchunked/chunked functions backwards compatibility security considerations copyright abstract the following standardizes an api for directories and files within smart contracts, similar to traditional filesystems. this standard provides basic functionality to read/write binary objects of any size, as well as allow reading/writing chunks of the object if the object is too large to fit in a single transaction. motivation a standard interface allows any binary objects on evm-based blockchain to be re-used by other dapps. with eip-4804, we are able to locate a web3 resource on blockchain using http-style uris. one application of web3 resources are web contents that are referenced within a directory using relative paths such as html/svg. this standard proposes a contract-based directory to simplify the mapping between local web contents and on-chain web contents. further, with relative paths referenced in the web contents and eip-4804, the users will have a consistent view of the web contents locally and on-chain. specification directory methods write writes binary data to the file name in the directory by an account with write permission. function write(bytes memory name, bytes memory data) external payable read returns the binary data from the file name in the directory and existence of the file. function read(bytes memory name) external view returns (bytes memory data, bool exist) fallback read returns the binary data from the file prefixedname (prefixed with /) in the directory. fallback(bytes calldata prefixedname) external returns (bytes memory data) size returns the size of the data from the file name in the directory and the number of chunks of the data. function size(bytes memory name) external view returns (uint256 size, uint256 chunks) remove removes the file name in the directory and returns the number of chunks removed (0 means the file does not exist) by an account with write permission. function remove(bytes memory name) external returns (uint256 numofchunksremoved) countchunks returns the number of chunks of the file name. function countchunks(bytes memory name) external view returns (uint256 numofchunks); writechunk writes a chunk of data to the file by an account with write permission. the write will fail if chunkid > numofchunks, i.e., the write must append the file or replace the existing chunk. function writechunk(bytes memory name, uint256 chunkid, bytes memory chunkdata) external payable; readchunk returns the chunk data of the file name and the existence of the chunk. function readchunk(bytes memory name, uint256 chunkid) external view returns (bytes memory chunkdata, bool exist); chunksize returns the size of a chunk of the file name and the existence of the chunk. function chunksize(bytes memory name, uint256 chunkid) external view returns (uint256 chunksize, bool exist); removechunk removes a chunk of the file name and returns false if such chunk does not exist. the method should be called by an account with write permission. function removechunk(bytes memory name, uint256 chunkid) external returns (bool exist); truncate removes the chunks of the file name in the directory from the given chunkid and returns the number of chunks removed by an account with write permission. when chunkid = 0, the method is essentially the same as remove(). function truncate(bytes memory name, uint256 chunkid) external returns (uint256 numofchunksremoved); getchunkhash returns the hash value of the chunk data. function getchunkhash(bytes memory name, uint256 chunkid) external view returns (bytes32); rationale one issue of uploading the web contents to the blockchain is that the web contents may be too large to fit into a single transaction. as a result, the standard provides chunk-based operations so that uploading a content can be split into several transactions. meanwhile, the read operation can be done in a single transaction, i.e., with a single web3 url defined in eip-4804. interactions between unchunked/chunked functions read method should return the concatenated chunked data written by writechunk method. the following gives some examples of the interactions: read("hello.txt") => “” (file is empty) writechunk("hello.txt", 0, "abc") will succeed read("hello.txt") => “abc” writechunk("hello.txt", 1, "efg") will succeed read("hello.txt") => “abcefg” writechunk("hello.txt", 0, "aaa") will succeed (replace chunk 0’s data) read("hello.txt") => “aaaefg” writechunk("hello.txt", 3, "hij") will fail because the operation is not replacement or append. with writechunk method, we allow writing a file with external data that exceeds the current calldata limit (e.g., 1.8mb now), and it is able to read the whole file in a single read method (which is friendly for large web objects such as html/svg/png/jpg, etc). for write method, calling a write method will replace all data chunks of the file with write method data, and one implementation can be: writechunk(filename, chunkid=0, data_from_write) to chunk 0 with the same write method data; and truncate(filename, chunkid=1), which will remove the rest chunks. backwards compatibility no backwards compatibility issues were identified. security considerations no security considerations were found. copyright copyright and related rights waived via cc0. citation please cite this document as: qi zhou (@qizhou), "erc-5018: filesystem-like interface for contracts [draft]," ethereum improvement proposals, no. 5018, april 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5018. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-4494: permit for erc-721 nfts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-4494: permit for erc-721 nfts erc-712-singed approvals for erc-721 nfts authors simon fremaux (@dievardump), william schwab (@wschwab) created 2021-11-25 discussion link https://ethereum-magicians.org/t/eip-extending-erc2612-style-permits-to-erc721-nfts/7519/2 requires eip-165, eip-712, eip-721 table of contents abstract motivation specification rationale backwards compatibility test cases reference implementation security considerations copyright abstract the “permit” approval flow outlined in erc-2612 has proven a very valuable advancement in ux by creating gasless approvals for erc20 tokens. this eip extends the pattern to erc-721 nfts. this eip borrows heavily from erc-2612. this requires a separate eip due to the difference in structure between erc-20 and erc-721 tokens. while erc-20 permits use value (the amount of the erc-20 token being approved) and a nonce based on the owner’s address, erc-721 permits focus on the tokenid of the nft and increment nonce based on the transfers of the nft. motivation the permit structure outlined in erc-2612 allows for a signed message (structured as outlined in erc-712) to be used in order to create an approval. whereas the normal approval-based pull flow generally involves two transactions, one to approve a contract and a second for the contract to pull the asset, which is poor ux and often confuses new users, a permit-style flow only requires signing a message and a transaction. additional information can be found in erc-2612. erc-2612 only outlines a permit architecture for erc-20 tokens. this erc proposes an architecture for erc-721 nfts, which also contain an approve architecture that would benefit from a signed message-based approval flow. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. three new functions must be added to erc-721: pragma solidity 0.8.10; import "./ierc165.sol"; /// /// @dev interface for token permits for erc-721 /// interface ierc4494 is ierc165 { /// erc165 bytes to add to interface array set in parent contract /// /// _interface_id_erc4494 = 0x5604e225 /// @notice function to approve by way of owner signature /// @param spender the address to approve /// @param tokenid the index of the nft to approve the spender on /// @param deadline a timestamp expiry for the permit /// @param sig a traditional or eip-2098 signature function permit(address spender, uint256 tokenid, uint256 deadline, bytes memory sig) external; /// @notice returns the nonce of an nft useful for creating permits /// @param tokenid the index of the nft to get the nonce of /// @return the uint256 representation of the nonce function nonces(uint256 tokenid) external view returns(uint256); /// @notice returns the domain separator used in the encoding of the signature for permits, as defined by eip-712 /// @return the bytes32 domain separator function domain_separator() external view returns(bytes32); } the semantics of which are as follows: for all addresses spender, uint256s tokenid, deadline, and nonce, and bytes sig, a call to permit(spender, tokenid, deadline, sig) must set spender as approved on tokenid as long as the owner of tokenid remains in possession of it, and must emit a corresponding approval event, if and only if the following conditions are met: the current blocktime is less than or equal to deadline the owner of the tokenid is not the zero address nonces[tokenid] is equal to nonce sig is a valid secp256k1 or eip-2098 signature from owner of the tokenid: keccak256(abi.encodepacked( hex"1901", domain_separator, keccak256(abi.encode( keccak256("permit(address spender,uint256 tokenid,uint256 nonce,uint256 deadline)"), spender, tokenid, nonce, deadline)) )); where domain_separator must be defined according to eip-712. the domain_separator should be unique to the contract and chain to prevent replay attacks from other domains, and satisfy the requirements of eip-712, but is otherwise unconstrained. a common choice for domain_separator is: domain_separator = keccak256( abi.encode( keccak256('eip712domain(string name,string version,uint256 chainid,address verifyingcontract)'), keccak256(bytes(name)), keccak256(bytes(version)), chainid, address(this) )); in other words, the message is the following erc-712 typed structure: { "types": { "eip712domain": [ { "name": "name", "type": "string" }, { "name": "version", "type": "string" }, { "name": "chainid", "type": "uint256" }, { "name": "verifyingcontract", "type": "address" } ], "permit": [ { "name": "spender", "type": "address" }, { "name": "tokenid", "type": "uint256" }, { "name": "nonce", "type": "uint256" }, { "name": "deadline", "type": "uint256" } ], "primarytype": "permit", "domain": { "name": erc721name, "version": version, "chainid": chainid, "verifyingcontract": tokenaddress }, "message": { "spender": spender, "value": value, "nonce": nonce, "deadline": deadline } }} in addition: the nonce of a particular tokenid (nonces[tokenid]) must be incremented upon any transfer of the tokenid the permit function must check that the signer is not the zero address note that nowhere in this definition do we refer to msg.sender. the caller of the permit function can be any address. this eip requires eip-165. eip165 is already required in erc-721, but is further necessary here in order to register the interface of this eip. doing so will allow easy verification if an nft contract has implemented this eip or not, enabling them to interact accordingly. the interface of this eip (as defined in eip-165) is 0x5604e225. contracts implementing this eip must have the supportsinterface function return true when called with 0x5604e225. rationale the permit function is sufficient for enabling a safetransferfrom transaction to be made without the need for an additional transaction. the format avoids any calls to unknown code. the nonces mapping is given for replay protection. a common use case of permit has a relayer submit a permit on behalf of the owner. in this scenario, the relaying party is essentially given a free option to submit or withhold the permit. if this is a cause of concern, the owner can limit the time a permit is valid for by setting deadline to a value in the near future. the deadline argument can be set to uint(-1) to create permits that effectively never expire. erc-712 typed messages are included because of its use in erc-2612, which in turn cites widespread adoption in many wallet providers. while erc-2612 focuses on the value being approved, this eip focuses on the tokenid of the nft being approved via permit. this enables a flexibility that cannot be achieved with erc-20 (or even erc-1155) tokens, enabling a single owner to give multiple permits on the same nft. this is possible since each erc-721 token is discrete (oftentimes referred to as non-fungible), which allows assertion that this token is still in the possession of the owner simply and conclusively. whereas erc-2612 splits signatures into their v,r,s components, this eip opts to instead take a bytes array of variable length in order to support eip-2098 signatures (64 bytes), which cannot be easily separated or reconstructed from r,s,v components (65 bytes). backwards compatibility there are already some erc-721 contracts implementing a permit-style architecture, most notably uniswap v3. their implementation differs from the specification here in that: the permit architecture is based on owner the nonce is incremented at the time the permit is created the permit function must be called by the nft owner, who is set as the owner the signature is split into r,s,v instead of bytes rationale for differing on design decisions is detailed above. test cases basic test cases for the reference implementation can be found here. in general, test suites should assert at least the following about any implementation of this eip: the nonce is incremented after each transfer permit approves the spender on the correct tokenid the permit cannot be used after the nft is transferred an expired permit cannot be used reference implementation a reference implementation has been set up here. security considerations extra care should be taken when creating transfer functions in which permit and a transfer function can be used in one function to make sure that invalid permits cannot be used in any way. this is especially relevant for automated nft platforms, in which a careless implementation can result in the compromise of a number of user assets. the remaining considerations have been copied from erc-2612 with minor adaptation, and are equally relevant here: though the signer of a permit may have a certain party in mind to submit their transaction, another party can always front run this transaction and call permit before the intended party. the end result is the same for the permit signer, however. since the ecrecover precompile fails silently and just returns the zero address as signer when given malformed messages, it is important to ensure ownerof(tokenid) != address(0) to avoid permit from creating an approval to any tokenid which does not have an approval set. signed permit messages are censorable. the relaying party can always choose to not submit the permit after having received it, withholding the option to submit it. the deadline parameter is one mitigation to this. if the signing party holds eth they can also just submit the permit themselves, which can render previously signed permits invalid. the standard erc-20 race condition for approvals applies to permit as well. if the domain_separator contains the chainid and is defined at contract deployment instead of reconstructed for every signature, there is a risk of possible replay attacks between chains in the event of a future chain split. copyright copyright and related rights waived via cc0. citation please cite this document as: simon fremaux (@dievardump), william schwab (@wschwab), "erc-4494: permit for erc-721 nfts [draft]," ethereum improvement proposals, no. 4494, november 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4494. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2464: eth/65: transaction announcements and retrievals ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: networking eip-2464: eth/65: transaction announcements and retrievals introduces `newpooledtransactionhashes`, `getpooledtransactions`, and `pooledtransactions`. authors péter szilágyi , péter szilágyi (@karalabe), gary rong , tim beiko (@timbeiko) created 2020-01-13 requires eip-2364 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip introduces three additional message types into the eth protocol (releasing a new version, eth/65): newpooledtransactionhashes (0x08) to announce a set of transactions without their content; getpooledtransactions (0x09) to request a batch of transactions by their announced hash; and pooledtransactions (0x0a) to reply to a transaction request. this permits reducing the bandwidth used for transaction propagation from linear complexity in the number of peers to square root; and also reducing the initial transaction exchange from 10s-100s mb to len(pool) * 32b ~= 128kb. motivation the eth network protocol has two ways to propagate a newly mined block: it can be broadcast to a peer in its entirety (via newblock (0x07) in eth/64 and prior or it can be announced only (via newblockhashes (0x01)). this duality allows nodes to do the high-bandwidth broadcasting (10s-100s kb) for a square root number of peers; and the low-bandwidth announcing (10s-100s b) for the remaining linear number of peers. the square root broadcast is enough to reach all well connected nodes, but the linear announce is needed to get across degenerate topologies. this works well. the eth protocol, however, does not have a similar dual mechanism for propagating transactions, so nodes need to rely on broadcasting (via transactions (0x02)). to cater for degenerate topologies, transactions cannot be broadcast square rooted, rather they need to be transferred linearly to all peers. with n peers, each node will transfer the same transaction n times (counting both directions), whereas 1 would be enough in a perfect world. this is a significant waste. a similar issue arises when a new network connection is made between two nodes, as they need to sync up their transaction pools, but the pool is just a soup of dangling transactions. without a way to deduplicate transactions remotely, each node is forced to naively transfer their entire list of transactions to the other side. with pools containing thousands of transactions, a naive transfer amounts to 10s-100s mb, most of which is useless. there is no better way, however. this eip introduces three additional message types into the eth protocol (releasing a new version, eth/65): newpooledtransactionhashes (0x08) to announce a set of transactions without their content; getpooledtransactions (0x09) to request a batch of transactions by their announced hash; and pooledtransactions (0x0a) to reply to a transaction request. this permits reducing the bandwidth used for transaction propagation from linear complexity in the number of peers to square root; and also reducing the initial transaction exchange from 10s-100s mb to len(pool) * 32b ~= 128kb. with transaction throughput (and size) picking up in ethereum, transaction propagation is the current dominant component of the used network resources. most of these resources are however wasted, as the eth protocol does not have a mechanism to deduplicate transactions remotely, so the same data is transferred over and over again across all network connections. this eip proposes a tiny extension to the eth protocol, which permits nodes to agree on the set of transactions that need to be transferred across a network connection, before doing the costly exchange. this should help reduce the global (operational) bandwidth usage of the ethereum network by at least an order of magnitude. specification add three new message types to the eth protocol: newpooledtransactionhashes (0x08): [hash_0: b_32, hash_1: b_32, ...] specify one or more transactions that have appeared in the network and which have not yet been included in a block. to be maximally helpful, nodes should inform peers of all transactions that they may not be aware of. there is no protocol violating hard cap on the number of hashes a node may announce to a remote peer (apart from the 10mb devp2p network packet limit), but 4096 seems a sane chunk (128kb) to avoid a single packet hogging a network connection. nodes should only announce hashes of transactions that the remote peer could reasonably be considered not to know, but it is better to be over zealous than to have a nonce gap in the pool. getpooledtransactions (0x09): [hash_0: b_32, hash_1: b_32, ...] specify one or more transactions to retrieve from a remote peer’s transaction pool. there is no protocol violating hard cap on the number of transactions a node may request from a remote peer (apart from the 10mb devp2p network packet limit), but the recipient may enforce an arbitrary cap on the reply (size or serving time), which must not be considered a protocol violation. to keep wasted bandwidth down (unanswered hashes), 256 seems like a sane upper limit. pooledtransactions (0x0a): [[nonce: p, receivingaddress: b_20, value: p, ...], ...] specify transactions from the local transaction pool that the remote node requested via a getpooledtransactions (0x09) message. the items in the list are transactions in the format described in the main ethereum specification. the transactions must be in same order as in the request, but it is ok to skip transactions that are not available. this way if the response size limit is reached, requesters will know which hashes to request again (everything from the last returned transaction) and which to assume unavailable (all gaps before the last returned transaction). a peer may respond with an empty reply iff none of the hashes match transactions in its pool. it is allowed to announce a transaction that will not be served later if it gets included in a block in between. rationale q: why limit getpooledtransactions (0x09) to retrieving items from the pool? apart from the transaction pool, transactions in ethereum are always bundled together by the hundreds in block bodies and existing network retrievals honor this data layout. allowing direct access to individual transactions in the database has no actionable use case, but would expose costly database reads into the network. for transaction propagation purposes there is no reason to allow disk access, as any transaction finalized to disk will be broadcast inside a block anyway, so at worse there is a few hundred millisecond delay when a node gets the transaction. block propagation may be made a bit more optimal by transferring the contained transactions on demand only, but that is a whole eip in itself, so better relax the protocol when all the requirements are known and not in advance. it would probably be enough to maintain a set of transactions included in recent blocks in memory. q: should newpooledtransactionhashes (0x08) deduplicate from disk? similarly to getpooledtransactions (0x09), newpooledtransactionhashes (0x08) should also only operate on the transaction pool and should ignore the disk altogether. during healthy network conditions, a transaction will propagate through much faster than it’s included in a block, so it will essentially be non-existent that a newly announced transaction is already on disk. by avoiding disk deduplication, we can avoid a dos griefing by remote transaction announces. if we want to be really correct and avoid even the slightest data race when deduplicating announcements, we can use the same recently-included-transactions trick that we discussed above to discard announcements that have recently become stale. q: why not reuse transaction (0x02) instead of a new pooledtransactions (0x0a)? originally this eip reused the existing transaction (0x02) message as the reply to the getpooledtransactions (0x09) request. this makes client code more complicated, because nodes constantly gossip transaction (0x02) messages to each other as broadcasts, so it’s hard to match up which of the many messages is the actual reply to the request. by keeping transaction (0x02) and pooledtransactions (0x0a) as separate messages, we can also leave the protocol more flexible for future optimizations (e.g. adding request ids, which are meaningless for gossip broadcasts). backwards compatibility this eip extends the eth protocol in a backwards incompatible way and requires rolling out a new version, eth/65. however, devp2p supports running multiple versions of the same wire protocol side-by-side, so rolling out eth/65 does not require client coordination, since non-updated clients can keep using eth/64. this eip does not change the consensus engine, thus does not require a hard fork. security considerations none. copyright copyright and related rights waived via cc0. citation please cite this document as: péter szilágyi , péter szilágyi (@karalabe), gary rong , tim beiko (@timbeiko), "eip-2464: eth/65: transaction announcements and retrievals," ethereum improvement proposals, no. 2464, january 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2464. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6065: real estate token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: erc erc-6065: real estate token an interface for real estate nfts that extends erc-721 authors alex (@alex-klasma), ben fusek (@bfusek), daniel fallon-cyr (@dfalloncyr) created 2022-11-29 requires eip-721 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification token components: interfaces rationale introduction guiding objectives operatingagreementhashof property unique identifiers debtof managerof backwards compatibility reference implementation legal structure implementation security considerations copyright abstract this proposal introduces an open structure for physical real estate and property to exist on the blockchain. this standard builds off of erc-721, adding important functionality necessary for representing real world assets such as real estate. the three objectives this standard aims to meet are: universal transferability of the nft, private property rights attached to the nft, and atomic transfer of property rights with the transfer of the nft. the token contains a hash of the operating agreement detailing the nft holder’s legal right to the property, unique identifiers for the property, a debt value and foreclosure status, and a manager address. motivation real estate is the largest asset class in the world. by tokenizing real estate, barriers to entry are lowered, transaction costs are minimized, information asymmetry is reduced, ownership structures become more malleable, and a new building block for innovation is formed. however, in order to tokenize this asset class, a common standard is needed that accounts for its real world particularities while remaining flexible enough to adapt to various jurisdictions and regulatory environments. ethereum tokens involving real world assets (rwas) are notoriously tricky. this is because ethereum tokens exist on-chain, while real estate exists off-chain. as such, the two are subject to entirely different consensus environments. for ethereum tokens, consensus is reached through a formalized process of distributed validators. when a purely-digital nft is transferred, the new owner has a cryptographic guarantee of ownership. for real estate, consensus is supported by legal contracts, property law, and enforced by the court system. with existing asset-backed erc-721 tokens, a transfer of the token to another individual does not necessarily have any impact on the legal ownership of the physical asset. this standard attempts to solve the real world reconciliation issue, enabling real estate nfts to function seamlessly on-chain, just like their purely-digital counterparts. 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. in order to meet the above objectives and create an open standard for on-chain property ownership we have created a token structure that builds on the widely-used erc-721 standard. token components: inherits erc-721 allows for backwards compatibility with the most widely accepted nft token standard. operatingagreementhashof immutable hash of the legal agreement detailing the right to ownership and conditions of use with regard to the property property unique identifiers legal description (from physical deed), street address, gis coordinates, parcel/tax id, legal owning entity (on deed) debtof readable debt value, currency, and foreclosure status of the nft managerof readable ethereum address with managing control of property interfaces this eip inherits the erc-721 nft token standard for all transfer and approval logic. all transfer and approval functions are inherited from this token standard without changes. additionally, this eip also inherits the erc-721 metadata standards for name, symbol, and metadata uri lookup. this allows an nft under this eip to become interoperable with preexisting nft exchanges and services, however, some care must be taken. please refer to backwards compatibility and security considerations. solidity interface pragma solidity ^0.8.13; import "forge-std/interfaces/ierc721.sol"; interface ierc6065 is ierc721 { // this event must emit if the asset is ever foreclosed. event foreclosed(uint256 id); /* next getter functions return immutable data for nft. */ function legaldescriptionof(uint256 _id) external view returns (string memory); function addressof(uint256 _id) external view returns (string memory); function geojsonof(uint256 _id) external view returns (string memory); function parcelidof(uint256 _id) external view returns (string memory); function legalownerof(uint256 _id) external view returns (string memory); function operatingagreementhashof(uint256 _id) external view returns (bytes32); /* next getter function returns the debt denomination token of the nft, the amount of debt (negative debt == credit), and if the underlying asset backing the nft has been foreclosed on. this should be utilized specifically for off-chain debt and required payments on the rwa asset. it's recommended that administrators only use a single token type to denominate the debt. it's unrealistic to require integrating smart contracts to implement possibly unbounded tokens denominating the off-chain debt of an asset. if the foreclosed status == true, then the rwa can be seen as severed from the nft. the nft is now "unbacked" by the rwa. */ function debtof(uint256 _id) external view returns (address debttoken, int256 debtamt, bool foreclosed); // get the managerof an nft. the manager can have additional rights to the nft or rwa on or off-chain. function managerof(uint256 _id) external view returns (address); } rationale introduction real world assets operate in messy, non-deterministic environments. because of this, validating the true state of an asset can be murky, expensive, or time-consuming. for example, in the u.s., change of property ownership is usually recorded at the county recorder’s office, sometimes using pen and paper. it would be infeasible to continuously update this manual record every time an nft transaction occurs on the blockchain. additionally, since real world property rights are enforced by the court of law, it is essential that property ownership be documented in such a way that courts are able to interpret and enforce ownership if necessary. for these reasons, it is necessary to have a trusted party tasked with the responsibility of ensuring the state of the on-chain property nft accurately mirrors its physical counterpart. by having an administrator for the property who issues a legally-binding digital representation of the physical property, we are able to solve for both the atomic transfer of the property rights with the transfer of the nft, as well as institute a seamless process for making the necessary payments and filings associated with property ownership. this is made possible by eliminating the change in legal ownership each time the nft changes hands. an example administrator legal structure implemented for property tokenization in the u.s. is provided in the reference implementation. while a token that implements this standard must have a legal entity to conduct the off-chain dealings for the property, this implementation is not mandatory. guiding objectives we have designed this eip to achieve three primary objectives necessary for creating an nft representation of physical real estate: 1. real estate nfts are universally transferable a key aspect to private property is the right to transfer ownership to any legal person or entity that has the capacity to own that property. therefore, an nft representation of physical property should maintain that universal freedom of transfer. 2. all rights associated with property ownership are able to be maintained and guaranteed by the nft the rights associated with private property ownership are the right to hold, occupy, rent, alter, resell, or transfer the property. it is essential that these same rights are able to be maintained and enforced with an nft representation of real estate. 3. property rights are transferred atomically with the transfer of the nft token ownership on any blockchain is atomic with the transfer of the digital token. to ensure the digital representation of a physical property is able to fully integrate the benefits of blockchain technology, it is essential the rights associated with the property are passed atomically with the transfer of the digital token. the following section specifies the technological components required to meet these three objectives. operatingagreementhashof an immutable hash of the legal document issued by the legal entity that owns the property. the agreement is unique and contains the rights, terms, and conditions for the specific property represented by the nft. the hash of the agreement attached to the nft must be immutable to ensure the legitimacy and enforceability of these rights in the future for integrators or transferees. upon transfer of the nft, these legal rights are immediately enforceable by the new owner. for changes to the legal structure or rights and conditions with regard to the property the original token must be burned and a new token with the new hash must be minted. property unique identifiers the following unique identifiers of the property are contained within the nft and are immutable: legaldescriptionof: written description of the property taken from the physical property deed addressof: street address of the property geojsonof: the geojson format of the property’s geospatial coordinates parcelidof: id number used to identify the property by the local authority legalownerof: the legal entity that is named on the verifiable physical deed these unique identifiers ensure the physical property in question is clear and identifiable. these strings must be immutable to make certain that the identity of the property can not be changed in the future. this is necessary to provide confidence in the nft holder in the event a dispute about the property arises. these identifiers, especially legalownerof, allow for individuals to verify off-chain ownership and legitimacy of the legal agreement. these verification checks could be integrated with something like chainlink functions in the future to be simplified and automatic. debtof a readable value of debt and denoted currency that is accrued to the property. a positive balance signifies a debt against the property, while a negative balance signifies a credit which can be claimed by the nft owner. this is a way for the property administrator to charge the nft holder for any necessary payments towards the property, like property tax, or other critical repairs or maintenance in the “real world”. a credit might be given to the nft holder via this same function, perhaps the administrator and the nft holder had worked out a property management or tenancy revenue-sharing agreement. the debtof function also returns the boolean foreclosure status of the asset represented by the nft. a true result indicates the associated property is no longer backing the nft, a false result indicates the associated property is still backing the nft. an administrator can foreclose an asset for any reason as specified in the operating agreement, an example would be excessive unpaid debts. smart contracts can check the foreclosure state by calling this function. if the asset is foreclosed, it should be understood that the rwa backing the nft has been removed, and smart contracts should take this into account when doing any valuations or other calculations. there are no standard requirements for how these values are updated as those details will be decided by the implementor. this eip does however standardize how these values are indicated and read for simplicity of integration. managerof a readable ethereum address that can be granted a right to action on the property without being the underlying owner of the nft. this function allows the token to be owned by one ethereum address while granting particular rights to another. this enables protocols and smart contracts to own the underlying asset, such as a lending protocol, but still allow another ethereum address, such as a depositor, to action on the nft via other integrations, for example the administrator management portal. the standard does not require a specific implementation of the manager role, only the value is required. in many instances the managerof value will be the same as the owning address of the nft. backwards compatibility this eip is backwards compatible with erc-721. however, it is important to note that there are potential implementation considerations to take into account before any smart contract integration. see security considerations for more details. reference implementation klasma labs offers a work in progress reference implementation. the technical implementation includes the following additional components for reference, this implementation is not required. summary of this implementation: nft burn and mint function immutable nft data (unique identifiers and operating agreement hash) simple debt tracking by administrator blocklist function to freeze asset held by fraudulent addresses (note: to be implemented in the future) simple foreclosure logic initiated by administrator managerof function implementation to chain this call to other supported smart contracts legal structure implementation this section explains the legal structure and implementation a company may employ as an administrator of this token. the structure detailed below is specific to property tokenization in the u.s. in the 2023 regulatory environment. this section details an implementation of the legal standard that could be used by a company specifically for property tokenization in the u.s. in the 2022 regulatory environment. the legal structure for this token is as follows: a parent company and property administrator, owns a bankruptcy remote llc for each individual property they act as administrator for. the bankruptcy remote llc is the owner and manager of a dao llc. the dao llc is on the title and deed and issues the corresponding nft and operating agreement for the property. this structure enables the following three outcomes: homeowners are shielded from any financial stress or bankruptcy their physical asset administrator encounters. in the event of an administrator bankruptcy or dissolution the owner of the nft is entitled to transfer of the dao llc, or the sale and distribution of proceeds from the property. transfer of the rights to the property are atomic with the transfer of the nft. the nft represents a right to claim the asset and have the title transferred to the nft owner, as well as the right to use the asset. this ensures the rights to the physical property are passed digitally with the transfer of the nft, without having to update the legal owner of the property after each transfer. security note: in the event of a private key hack the company will likely not be able to reissue a home nft. home nft owners who are not confident in their ability to safely store their home nft will have varying levels of security options (multi-sigs, custodians, etc.). for public, large protocol hacks, the company may freeze the assets using the blocklist function and reissue the home nfts to the original owners. blocklist functionality is to-be-implemented in the reference implementation above. security considerations the following are checks and recommendations for protocols integrating nfts under this standard. these are of particular relevance to applications which lend against any asset utilizing this standard. protocol integrators are recommended to check that the unique identifiers for the property and the hash of the operating agreement are immutable for the specific nfts they wish to integrate. for correct implementation of this standard these values must be immutable to ensure legitimacy for future transferees. protocol integrators are recommended to check the debtof value for an accurate representation of the value of this token. protocol integrators are recommended to check the foreclose status to ensure this token is still backed by the asset it was originally tied to. for extra risk mitigation protocol integrators can implement a time-delay before performing irreversible actions. this is to protect against potential asset freezes if a hacked nft is deposited into the protocol. asset freezes are non-mandatory and subject to the implementation of the asset administrator. copyright copyright and related rights waived via cc0. citation please cite this document as: alex (@alex-klasma), ben fusek (@bfusek), daniel fallon-cyr (@dfalloncyr), "erc-6065: real estate token [draft]," ethereum improvement proposals, no. 6065, november 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6065. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-3450: standardized shamir secret sharing scheme for bip-39 mnemonics ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-3450: standardized shamir secret sharing scheme for bip-39 mnemonics authors daniel streit (@danielstreit) created 2021-03-29 discussion link https://ethereum-magicians.org/t/erc-3450-standard-for-applying-shamirs-to-bip-39-mnemonics/5844 table of contents simple summary abstract motivation specification shamir’s secret sharing scheme bip-39 mnemonics applying shamir’s scheme to bip-39 mnemonics share format creating shares recovering the mnemonic rationale choice of field valid share mnemonics and share ids validation on recovery test cases security considerations copyright simple summary a standardized algorithm for applying shamir’s secret sharing scheme to bip-39 mnemonics. abstract a standardized approach to splitting a bip-39 mnemonic into n bip-39 mnemonics, called shares, so that t shares are required to recover the original mnemonic and no information about the original mnemonic, other than its size, is leaked with less than t shares. motivation we’d like to make it easier for less-technical users to store keys securely. currently, many users use bip-39 mnemonics to store entropy values underlying their keys. these mnemonics are a single point of failure. if lost, the user may never regain access to the assets locked by the keys. if stolen, a malicious actor can steal the assets. shamir’s secret sharing scheme addresses this concern directly. it creates “shares” of the secret, such that a subset can be used to recover the secret, but only if a minimum threshold of shares is reached. without the minimum, no information about the original secret is leaked. one concern with shamir’s secret sharing scheme is there is no canonical, standard implementation. this puts recovery at risk, as tooling may change over time. here, we propose a standardized implementation of shamir’s secret sharing scheme applied specifically to bip-39 mnemonics, so users can easily create shares of their mnemonic, destroy the original, store the shares appropriately, and confidently recover the original mnemonic at a later date. specification shamir’s secret sharing scheme shamir’s secret sharing scheme is a cryptographic method to split a secret into n unique parts, where any t of them are required to reconstruct the secret. first, a polynomial f of degree t − 1 is constructed. then, each share is a point on the polynomial’s curve: an integer x, and its corresponding y point f(x). with any set of t shares (or points), the initial polynomial can be recovered using polynomial interpolation. when constructing the initial polynomial, the secret is stored as the coefficient of x0 and the rest of the coefficients are randomly generated. bip-39 mnemonics bip-39 is a common standard for storing entropy as a list of words. it is easier to work with for human interactions than raw binary or hexadecimal representations of entropy. bip-39 mnemonics encode two pieces of data: the original entropy and a checksum of that entropy. the checksum allows the mnemonic to be validated, ensuring that the user entered it correctly. generating the mnemonic the mnemonic must encode entropy in a multiple of 32 bits. with more entropy security is improved but the sentence length increases. we refer to the initial entropy length as ent. the allowed size of ent is 128-256 bits. first, an initial entropy of ent bits is generated. a checksum is generated by taking the first ent / 32 bits of its sha256 hash. this checksum is appended to the end of the initial entropy. next, these concatenated bits are split into groups of 11 bits, each encoding a number from 0-2047, serving as an index into a word list. finally, we convert these numbers into words and use the joined words as a mnemonic sentence. the following table describes the relation between the initial entropy length (ent), the checksum length (cs), and the length of the generated mnemonic sentence (ms) in words. cs = ent / 32 ms = (ent + cs) / 11 | ent | cs | ent+cs | ms | +-------+----+--------+------+ | 128 | 4 | 132 | 12 | | 160 | 5 | 165 | 15 | | 192 | 6 | 198 | 18 | | 224 | 7 | 231 | 21 | | 256 | 8 | 264 | 24 | recovering the entropy the initial entropy can be recovered by reversing the process above. the mnemonic is converted to bits, where each word is converted to 11 bits representing its index in the word list. the entropy portion is defined in the table above, based on the size of the mnemonic. word list this specification only supports the bip-39 english word list, but this may be expanded in the future. see word list. applying shamir’s scheme to bip-39 mnemonics to ensure that the shares are valid bip-39 mnemonics, we: convert the target bip-39 mnemonic to its underlying entropy apply shamir’s scheme to the entropy convert each resulting share’s y value to a bip-39 mnemonic by converting to entropy before applying shamir’s scheme, we omit the checksum from the initial secret, allowing us to calculate a new checksum for each share when converting the share y values to mnemonics, ensuring that they are valid according to bip-39. when applying shamir’s scheme to the entropy, we apply it separately to each byte of the entropy and gf(256) is used as the underlying finite field. bytes are interpreted as elements of gf(256) using polynomial representation with operations modulo the rijndael irreducible polynomial x8 + x4 + x3 + x + 1, following aes. share format a share represents a point on the curve described by the underlying polynomial used to split the secret. it includes two pieces of data: an id: the x value of the share a bip-39 mnemonic: the y value of the share represented by a mnemonic creating shares inputs: bip-39 mnemonic, number of shares (n), threshold (t) output: n shares, each share including an id, { x 0 < x < 256 }, and a bip-39 mnemonic of the same length as the input one check the following conditions: 1 < t <= n < 256 the mnemonic is valid according to bip-39 recover the underlying entropy of the mnemonic as a vector of bytes define values: let e be the byte-vector representation of the mnemonic’s entropy let n be the length of e let coeff1, … , coefft 1 be byte-vectors belonging to gf(256)n generated randomly, independently with uniform distribution from a source suitable for generating cryptographic keys evaluate the polynomial for each share for each x from 1 to n, evaluate the polynomial f(x) = e + coeff1x1 + … + coefft 1xt 1, where x is the share id and f(x) is the share value (as a vector of bytes) using f(x) as the underlying entropy, generate a mnemonic for each share return the id and mnemonic for each share recovering the mnemonic to recover the original mnemonic, we interpolate a polynomial f from the given set of shares (or points on the polynomial) and evaluate f(0). polynomial interpolation given a set of m points (xi, yi), 1 ≤ i ≤ m, such that no two xi values equal, there exists a polynomial that assumes the value yi at each point xi. the polynomial of lowest degree that satisfies these conditions is uniquely determined and can be obtained using the lagrange interpolation formula given below. since shamir’s secret sharing scheme is applied separately to each of the n bytes of the shared mnemonic’s entropy, we work with yi as a vector of n values, where yi[k] = fk(xi), 1 ≤ k ≤ n, and fk is the polynomial in the k-th instance of the scheme. interpolate(x, {(xi, yi), 1 ≤ i ≤ m}) input: the desired index x, a set of index/value-vector pairs {(xi, yi), 1 ≤ i ≤ m} ⊆ gf(256) × gf(256)n output: the value-vector (f1(x), … , fn(x)) recover the mnemonic input: a set of m shares output: the original mnemonic recover the underlying entropy of each share’s mnemonic as a vector of bytes calculate e = interpolate(0, [(x1, y1),…,(xm, ym)]), where x is the share id and y is the byte-vector of the share’s mnemonic’s entropy using e as the underlying entropy, generate a mnemonic and return it rationale choice of field the field gf(256) was chosen, because the field arithmetic is easy to implement in any programming language and many implementations are already available since it is used in the aes cipher. although using gf(256) requires that we convert the mnemonic to its underlying entropy as a byte-vector, this is also easy to implement and many implementations of it exist in a variety of programming languages. gf(2048) was also considered. using gf(2048), we could have applied shamir’s scheme directly to the mnemonic, using the word indexes as the values. this would have allowed us to avoid converting the mnemonic to its underlying entropy. but, the resulting shares would not have been valid bip-39 mnemonics the checksum portion would not be a valid checksum of the entropy. and, working around this would add considerable complexity. another option was gf(2n) where n is the size of the entropy in bits. we’d still convert the mnemonic to entropy, but then apply shamir’s scheme over the entire entropy rather than on a vector of values. the downside of this approach is we’d need a different field for each mnemonic strength along with an associated irreducible polynomial. additionally, this would require working with very large numbers that can be cumbersome to work with in some languages. valid share mnemonics and share ids the shares produced by the specification include an id, in addition to the bip-39 mnemonic. other options could have encoded the share id into the mnemonic, simplifying storage only the mnemonic would need to be stored. one possibility would be to store the id instead of the checksum in the mnemonic. the downside of this approach is that the shares would not be valid bip-39 mnemonics because the “checksum” section of the mnemonic would not match the “entropy” section. shares with valid bip-39 mnemonics are useful because they are indistinguishable from any other. and users could store the id in a variety of ways that obscure it. validation on recovery we decided not to include a validation mechanism on recovering the original mnemonic. this leaks less information to a potential attacker. there is no indication they’ve gotten the requisite number of shares until they’ve obtained t + 1 shares. we could provide recovery validation by replacing one of the random coefficients with a checksum of the original mnemonic. then, when recovering the original mnemonic and the polynomial, we could validate that the checksum coefficient is the valid checksum of recovered mnemonic. test cases coming soon. all implementations must be able to: split and recover each mnemonic with the given numshares and threshold. recover the mnemonic from the given knownshares. security considerations the shares produced by the specification include an id in addition to the bip-39 mnemonic. this raises two security concerns: users must keep this id in order to recover the original mnemonic. if the id is lost, or separated from the share mnemonic, it may not be possible to recover the original. (brute force recovery may or may not be possible depending on how much is known about the number of shares and threshold) the additional data may hint to an attacker of the existence of other keys and the scheme under which they are stored. therefore, the id should be stored in a way that obscures its use. copyright copyright and related rights waived via cc0. citation please cite this document as: daniel streit (@danielstreit), "erc-3450: standardized shamir secret sharing scheme for bip-39 mnemonics [draft]," ethereum improvement proposals, no. 3450, march 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3450. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5375: nft author information and consent ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-5375: nft author information and consent an extension of eip-721 for nft authorship and author consent. authors samuele marro (@samuelemarro), luca donno (@lucadonnoh) created 2022-07-30 requires eip-55, eip-155, eip-712, eip-721, eip-1155 table of contents abstract motivation specification definitions authorship support author consent author consent verification rationale why provide only an author consent proof? why off-chain? why repeat id, chainid and contractaddress? why not implement a revocation system? usability improvements for authors limitations of address-based consent backwards compatibility security considerations attacks deprecated features replay attack resistance copyright abstract this eip standardizes a json format for storing off-chain information about nft authors. specifically, it adds a new field which provides a list of author names, addresses, and proofs of authorship consent: proofs that the authors have agreed to be named as authors. note that a proof of authorship consent is not a proof of authorship: an address can consent without having authored the nft. motivation there is currently no standard to identify authors of an nft, and existing techniques have issues: using the mint tx.origin or msg.sender assumes that the minter and the author are the same does not support multiple authors using the first transfer event for a given id contract/minter can claim that someone else is the author without their consent does not support multiple authors using a custom method/custom json field requires per-contract support by nft platforms contract/minter can claim that someone else is the author without their consent the first practice is the most common. however, there are several situations where the minter and the author might not be the same, such as: nfts minted by a contract lazy minting nfts minted by an intermediary (which can be particularly useful when the author is not tech-savvy and/or the minting process is convoluted) this document thus defines a standard which allows the minter to provide authorship information, while also preventing authorship claims without the author’s consent. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. all addresses used in this standard must follow the casing rules described in eip-55. definitions authors: creators of an nft minter: entity responsible for the actual minting transaction; the minter and the authors may be the same verifier: entity that wants to verify the authorship of an nft (e.g. a user or an nft marketplace) author consent proof (acp): a signed message that proves that the signer agrees to be considered the author of the nft authorship support the standard introduces a new json field, named authorinfo. it provides a required interface for authorship claiming, as well as an optional interface for author consent proofs. authorinfo is a top-level field of the nft metadata. specifically: if a contract supports the metadata extension for eip-721, the json document pointed by tokenuri(uint256 _tokenid) must include the top-level field authorinfo if a contract supports the metadata extension for eip-1155, the json document pointed by uri(uint256 _id) must include a top-level field authorinfo the json schema of authorinfo (named erc5375authorinfoschema) is defined as follows: { "type": "object", "properties": { "consentinfo": { "type": "object", "description": "helper fields for consent verification", "properties": { "chainid": { "type": "integer", "description": "eip-155 chain id" }, "id": { "type": "string", "description": "nft id" }, "contractaddress": { "type": "string", "description": "0x-prefixed address of the smart contract" } } }, "authors": { "type": "array", "items": "erc5375authorschema" } }, "required": [ "authors" ] } note that authors may be an empty array. erc5375authorschema is defined as follows: { "type": "object", "properties": { "address": { "type": "string", "description": "0x-prefixed address of the author" }, "consent": { "type": "erc5375authorconsentschema", "description": "author consent information" } }, "required": [ "address" ] } moreover, if the consent field is present, the consentinfo field of authorinfo must be present. erc5375authorconsentschema is defined as follows: { "type": "object", "properties": { "consentdata": { "type": "object", "properties": { "version": { "type": "string", "description": "nft authorship consent schema version" }, "issuer": { "type": "string", "description": "0x-prefixed address of the author" }, "metadatafields": { "type": "object" } }, "required": ["version", "issuer", "metadatafields"] }, "publickey": { "type": "string", "description": "evm public key of the author" }, "signature": { "type": "string", "description": "eip-712 signature of the consent message" } }, "required": ["consentdata", "publickey", "signature"] } where metadatafields is an object containing the json top-level fields (excluding authorinfo) that the author will certify. note that the keys of metadatafields may be a (potentially empty) subset of the set of fields. consentdata may support additional fields as defined by other eips. consentdata must contain all the information (which is not already present in other fields) required to verify the validity of an authorship consent proof. author consent consent is obtained by signing an eip-712 compatible message. specifically, the structure is defined as follows: struct author { address subject; uint256 tokenid; string metadata; } where subject is the address of the nft contract, tokenid is the id of the nft and metadata is the json encoding of the fields listed in metadatafields. metadata: must contain exactly the same fields as the ones listed in metadatafields, in the same order must escape all non-ascii characters. if the escaped character contains hexadecimal letters, they must be uppercase must not contain any whitespace that is not part of a field name or value for example, if the top-level json fields are: { "name": "the holy hand grenade of antioch", "description": "throw in the general direction of your favorite rabbit, et voilà", "damage": 500, "authors": [...], ... } and the content of metadatafields is ["name", "description"], the content of metadata is: { "name": "the holy hand grenade of antioch", "description": "throw in the general direction of your favorite rabbit, et voil\u00e0" } similarly to consentdata, this structure may support additional fields as defined by other eips. the domain separator structure is struct eip712domain { string name; string version; uint256 chainid; } where name and version are the same fields described in consentdata this structure may support additional fields as defined by other eips. author consent verification verification is performed using eip-712 on an author-by-author basis. specifically, given a json document d1, a consent proof is valid if all of the following statements are true: d1 has a top-level authorinfo field that matches erc5375authorinfoschema consent exists and matches erc5375authorconsentschema; if calling tokenuri (for eip-721) or uri (for eip-1155) returns the uri of a json document d2, all the top-level fields listed in metadatafields must exist and have the same value; the eip-712 signature in signature (computed using the fields specified in the json document) is valid; verifiers must not assume that an nft with a valid consent proof from address x means that x is the actual author. on the other hand, verifiers may assume that if an nft does not provide a valid consent proof for address x, then x is not the actual author. rationale why provide only an author consent proof? adding support for full authorship proofs (i.e. alice is the author and no one else is the author) requires a protocol to prove that someone is the only author of an nft. in other words, we need to answer the question: “given an nft y and a user x claiming to be the author, is x the original author of y?”. for the sake of the argument, assume that there exists a protocol that, given an nft y, can determine the original author of y. even if such method existed, an attacker could slightly modify y, thus obtaining a new nft y’, and rightfully claim to be the author of y’, despite the fact that it is not an original work. real-world examples include changing some pixels of an image or replacing some words of a text with synonyms. preventing this behavior would require a general formal definition of when two nfts are semantically equivalent. even if defining such a concept were possible, it would still be beyond the scope of this eip. note that this issue is also present when using the minter’s address as a proxy for the author. why off-chain? there are three reasons: adding off-chain support does not require modifications to existing smart contracts; off-chain storage is usually much cheaper than on-chain storage, thus reducing the implementation barrier; while there may be some use cases for full on-chain authorship proofs (e.g. a marketplace providing special features for authors), there are limited applications for on-chain author consent, due to the fact that it is mostly used by users to determine the subjective value of an nft. why repeat id, chainid and contractaddress? in many cases, this data can be derived from contextual information. however, requiring their inclusion in the json document ensures that author consent can be verified using only the json document. why not implement a revocation system? authorship is usually final: either someone created an nft or they didn’t. moreover, a revocation system would impose additional implementation requirements on smart contracts and increase the complexity of verification. smart contracts may implement a revocation system, such as the one defined in other eips. why escape non-ascii characters in the signature message? eip-712 is designed with the possibility of on-chain verification in mind; while on-chain verification is not a priority for this eip, non-ascii characters are escaped due to the high complexity of dealing with non-ascii strings in smart contracts. usability improvements for authors since the author only needs to sign an eip-712 message, this protocol allows minters to handle the technical aspects of minting while still preserving the secrecy of the author’s wallet. specifically, the author only needs to: obtain an evm wallet; learn how to read and sign a eip-712 message (which can often be simplified by using a dapp) without needing to: obtain the chain’s native token (e.g. through trading or bridging); sign a transaction; understand the pricing mechanism of transactions; verify if a transaction has been included in a block this reduces the technical barrier for authors, thus increasing the usability of nfts, without requiring authors to hand over their keys to a tech-savvy intermediary. limitations of address-based consent the standard defines a protocol to verify that a certain address provided consent. however, it does not guarantee that the address corresponds to the expected author (such as the one provided in the name field). proving a link between an address and the entity behind it is beyond the scope of this document. backwards compatibility no backward compatibility issues were found. security considerations attacks a potential attack that exploits this eip involves tricking authors into signing authorship consent messages against their wishes. for this reason, authors must verify that all signature fields match the required ones. a more subtle approach involves not adding important fields to metadatafields. by doing so, the author signature might be valid even if the minter changes critical information. deprecated features erc5375authorinfoschema also originally included a field to specify a human-readable name for the author (without any kind of verification). this was scrapped due to the high risk of author spoofing, i.e.: alice mints an nft using bob’s name and alice’s address charlie does not check the address and instead relies on the provided name charlie buys alice’s nft while believing that it was created by bob for this reason, smart contract developers should not add support for unverifiable information to the json document. we believe that the most secure way to provide complex authorship information (e.g. the name of the author) is to prove that the information is associated with the author’s address, instead of with the nft itself. replay attack resistance the chain id, the contract address and the token id uniquely identify an nft; for this reason, there is no need to implement additional replay attack countermeasures (e.g. a nonce system). copyright copyright and related rights waived via cc0. citation please cite this document as: samuele marro (@samuelemarro), luca donno (@lucadonnoh), "erc-5375: nft author information and consent," ethereum improvement proposals, no. 5375, july 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5375. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3337: frame pointer support for memory load and store operations ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-3337: frame pointer support for memory load and store operations authors nick johnson (@arachnid) created 2021-03-06 discussion link https://ethereum-magicians.org/t/eips-3336-and-3337-improving-the-evms-memory-model/5482 requires eip-3336 table of contents simple summary abstract motivation specification parameters frame pointer setfp opcode getfp opcode mloadfp opcode mstorefp opcode rationale cost of new opcodes absence of mstore8fp backwards compatibility security considerations copyright simple summary introduces four new opcodes for loading data from and storing data to memory offset by a frame pointer. abstract this eip introduces four new opcodes, mloadfp, mstorefp, getfp and setfp that allow for more efficient memory access offset by a user-controlled quantity called the “frame pointer”. this permits compilers to more efficiently offload ephemeral data such as local variables to memory instead of the evm’s evaluation stack, which has a number of benefits, including the effective elimination of restrictions on the number of local variables in a function. motivation in most commonly used vms, ephemeral data such as local variables, function arguments, and return addresses is stored in a region of memory called the stack. in contrast to the evm’s evaluation stack, this area of memory is randomly accessible, and thus can store an arbitrary amount of data, which can be referenced from anywhere they remain in scope. although this model is possible in the current evm design, it is made difficult by the linear model of memory (addressed in eip-3336) and by the lack of opcodes for relative memory access commonly found in other architectures. this eip proposes new opcodes that permit this form of memory use, without imposing undue burden on evm implementers or on runtime efficiency. in the current evm model, a compiler wishing to use this pattern would have to store the frame pointer which points to the start or end of the current memory stack frame in memory, and load it each time they wish to reference it. for example, loading a value from memory offset by the frame pointer would require the following sequence of operations: opcode gas used pushn x 3 push1 0 3 mload 3 add 3 mload 3 this consumes a total of 15 gas, and takes up at least 7 bytes of bytecode each time it is referenced. in contrast, after this eip, the equivalent sequence of operations is: opcode gas used push1 x 3 mloadfp 3 this consumes only 6 gas, and takes at least 3 bytes of bytecode. the effort required from the evm implementation is equivalent, costing only one extra addition operation over a regular mload. the alternative of storing values on the stack, which requires 3 gas and 1 byte of bytecode for a dupn operation, but it is now at most twice as efficient rather than 5 times as efficient, making storing values in memory a viable alternative. likewise, before this eip a frame-pointer relative store requires the following sequence of operations: | opcode | gas used | |———–|———-| | pushn x | 3 | | push1 0 | 3 | | mload | 3 | | add | 3 | | mstore | 3 | this consumes 15 gas and at least 7 bytes of bytecode. after this eip, the equivalent sequence of operations is: opcode gas used pushn x 3 mstorefp 3 consuming only 6 gas and at least 3 bytes of bytecode, while once again only requiring evm implementations to do one extra addition operation. the alternative of storing values on the stack requires 6 gas and 2 bytes of bytecode for the sequence swapn pop, making it no more efficient than memory storage. specification parameters constant value fork_block tbd for blocks where block.number >= fork_block, the following changes apply. frame pointer a new evm internal state variable called the “frame pointer” is introduced. this is a signed integer that starts at 0. setfp opcode a new opcode, setfp is introduced with value 0x5c. this opcode costs g_low (3 gas) and takes one argument from the stack. the argument is stored as the new value of the frame pointer. getfp opcode a new opcode, getfp is introduced with value 0x5d. this opcode costs g_low (3 gas) and takes no arguments. it takes the current value of the frame pointer and pushes it to the stack. mloadfp opcode a new opcode mloadfp is introduced with value 0x5e. this opcode acts in all ways identical to mload, except that the value of the frame pointer is added to the address before loading data from memory. an attempt to load data from a negative address should be treated identically to an invalid opcode, consuming all gas and reverting the current execution context. mstorefp opcode a new opcode mstorefp is introduced with value 0x5f. this opcode acts in all ways identical to mstore, except that the value of the frame pointer is added to the address before storing data to memory. an attempt to store data to a negative address should be treated identically to an invalid opcode, consuming all gas and reverting the current execution context. rationale cost of new opcodes the cost of the new opcodes mloadfp and mstorefp reflects the cost of mload and mstore. they are generally equivalent in cost with the exception of an extra addition operation, which imposes negligible cost. the cost of the new opcodes setfp and getfp is based on other common low-cost opcodes such as push and pop. absence of mstore8fp mstore8fp opcode was not included because it is expected that it would be used infrequently, and there is a desire to minimise the size of the instruction set and to conserve opcodes for future use. backwards compatibility this eip exclusively introduces new opcodes, and as a result should not impact any existing programs unless they operate under the assumption that these opcodes are undefined, which we believe will not be the case. security considerations dos risks are mitigated by correct pricing of opcodes to reflect current execution costs. no other security considerations pertain to this eip. copyright copyright and related rights waived via cc0. citation please cite this document as: nick johnson (@arachnid), "eip-3337: frame pointer support for memory load and store operations [draft]," ethereum improvement proposals, no. 3337, march 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3337. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1679: hardfork meta: istanbul ethereum improvement proposals allcorenetworkinginterfaceercmetainformational meta eip-1679: hardfork meta: istanbul authors alex beregszaszi (@axic), afri schoedon (@5chdn) created 2019-01-04 requires eip-152, eip-1108, eip-1344, eip-1716, eip-1884, eip-2028, eip-2200 table of contents abstract specification activation included eips references copyright abstract this meta-eip specifies the changes included in the ethereum hardfork named istanbul. specification codename: istanbul activation block >= 9,069,000 on the ethereum mainnet block >= 6,485,846 on the ropsten testnet block >= 14,111,141 on the kovan testnet block >= 5,435,345 on the rinkeby testnet block >= 1,561,651 on the görli testnet included eips eip-152: add blake2 compression function f precompile eip-1108: reduce alt_bn128 precompile gas costs eip-1344: add chainid opcode eip-1884: repricing for trie-size-dependent opcodes eip-2028: calldata gas cost reduction eip-2200: rebalance net-metered sstore gas cost with consideration of sload gas cost change references included eips were finalized in all core devs call #68 https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), afri schoedon (@5chdn), "eip-1679: hardfork meta: istanbul," ethereum improvement proposals, no. 1679, january 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-1679. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. introducing block streams: a unified data stream capturing… | hedera hedera network services token service mint and configure tokens and accounts. consensus service verifiable timestamps and ordering of events. smart contracts run solidity smart contracts. hbar the hedera network's native cryptocurrency. insights how it works learn about hedera from end to end. explorers view live and historical data on hedera. dashboards analyze network activity and metrics. network nodes understand networks and node types. devs start building get started learn core concepts and build the future. documentation review the api and build using your favorite language. developer resources integrations plugins and microservices for hedera. fee estimator understand and estimate transaction costs. open source hedera is committed to open, transparent code. learning center learn about web3 and blockchain technologies. grants grants & accelerators for your project. bounties find bugs. submit a report. earn rewards. ecosystem ecosystem hedera ecosystem applications, developer tools, network explorers, and more. nft ecosystem metrics analyze on-chain and market nft ecosystem metrics. categories web3 applications connect into the innovative startups decentralizing the web on hedera. enterprise applications learn about the fortune 500 companies decentralizing the web on hedera. wallets & custodians create a hedera account to manage hbar, fungible tokens, and nfts. network explorers hedera mainnet and testnet graphical network explorers. developer tooling third-party apis, integrations, and plugins to build apps on hedera. grants & accelerators boost your project with support from the hedera ecosystem. partner program explore our partners to bring your vision into reality. hedera council over 30 highly diversified organizations govern hedera. use cases hedera solutions asset tokenization studio open source toolkit for tokenizing assets securely. stablecoin studio all-in-one toolkit for stablecoin solutions. hedera guardian auditable carbon markets and traceability. functional use cases data integrity & ai reliable, secure, and ethically governed insights. sustainability enabling fair carbon markets with trust. real-world asset tokenization seamless tokenization of real-world assets and digital at scale. consumer engagement & loyalty mint, distribute, and redeem loyalty rewards. decentralized identity maintain the lifecycle of credentials. decentralized logs scalable, real-time timestamped events. defi dapps built for the next-generation of finance. nfts low, fixed fees. immutable royalties. payments scalable, real-time, and affordable crypto-payments. hbar overview learn about hedera's token, hbar. treasury management hedera’s report of the hbar supply. governance decentralized governance hedera council see the world's leading organizations that own hedera. about meet hedera's board of directors and team. journey watch hedera's journey to build an empowered digital future for all. transparent governance public policy hedera's mission is to inform policy and regulation that impact the industry. meeting minutes immutably recorded on hedera. roadmap follow hedera's roadmap in its journey to build the future. resources company what's new partners papers careers media blog technical press podcast community events meetups store brand navigation quickstart introducing block streams: a unified data stream capturing the comprehensive history of the hedera network technical dec 27, 2024 by mark blackman senior director of product, hashgraph by mica cerone community development, hashgraph introducing block streams: a unified data stream capturing the comprehensive history of the hedera network the upcoming hedera network upgrade introduces early access to hip-1056: block streams, a new blockchain format for recording the hedera network's activities. this innovation marks a big step forward with all transaction output and state change data being exposed in a single, cryptographically verifiable stream of data. block streams will consolidate current output streams into a single, unified format. moreover, the inclusion of hedera state data redefines how developers and services interact with the network, enabling richer insights, improved efficiency, and streamlined integrations. tl;dr block streams are a new output stream that merges hedera’s existing event, record, and sidecar streams into a single stream of verifiable data. this consolidated approach primarily simplifies data consumption; however, with the inclusion of state data, it also unlocks new capabilities such as state proofs and interledger communication. each block within this stream is a self-contained, verifiable entity that encompasses: all events and transactions within a configurable number of consensus rounds. all resulting transaction output and state change data. a single network signature that attests to the validity of the block by a majority of hedera mainnet nodes. benefits of blockstreams 1. unified data stream block streams consolidate multiple data types into a single, cohesive stream, simplifying data consumption and processing for developers and services. 2. enhanced verifiability each block includes a bls network signature, proving it was signed by a majority of nodes representing a majority of the network's consensus stake weight. this feature simplifies the verification of the data, reducing mirror node processing and verification costs. 3. simplified consumption block streams are encoded using protobuf, enabling them to be easily consumable by any programming language with minimal complexity or dependencies, which increases accessibility for developers to work with hedera data. unlocking potential with state changes adding hedera state change data unlocks significant advantages by enabling off-network computation and verification of state. this capability empowers developers and services to achieve high performance, enhanced efficiency, and greater flexibility. some examples include: applications and off-chain services can cache and process hedera state locally, reducing latency and dependency on external data retrieval. applications and off-chain services can monitor and maintain contract state locally, enabling seamless interaction with hedera-based smart contracts. technical insights into blockstreams block items a block stream is a continuous sequence of data elements, known as block items, streamed from hedera consensus nodes to provide a verifiable record of hedera consensus and transaction processing. the sequence of block items is crucial for interpreting the block stream, as it not only defines the boundaries of individual blocks but also establishes the relationship between block items within a block. this ordered structure determines how blocks are extracted from the block stream, how transactions are linked to specific events, how events correlate with rounds, and how these components collectively define a block. the graphic below illustrates how the sequential ordering of block items represents the structure of a block and the data relationships connecting blocks, rounds, events, and transactions. block hash within each block, the block items are organized into a merkle-based tree structure, culminating in a root hash, known as the block hash. this structure ensures that each block’s data is consistent and accurately represented. this block hash is signed by a majority of consensus nodes using an aggregated signature, referred to as the block proof. the block proof provides cryptographic assurance that it has been processed, attested, and signed by a majority of hedera mainnet nodes. block item proof the block hash, block proof, and merkle tree structure of a block open up new opportunities for leveraging hedera's output data. among these advancements are block item proofs, which are cryptographic proofs for individual block items that allow verification of specific data within a block. these proofs empower users to independently verify all of hedera’s transactional history at minimal cost, even for offline devices. this capability not only enhances trust and transparency but also significantly broadens the range of use cases for hedera, from lightweight applications to secure offline verifications. blockchain structure hedera functions as a modular blockchain, achieving consensus through the hedera hashgraph while outputting data into a blockchain structure. this architecture ensures the security and immutability of the network's historical records. block streams build on this foundation by incorporating the hash of each preceding block into the next block, forming an immutable chain of data derived from hedera. the diagram below illustrates the merkle tree structure within a block, showcasing how the previous block's hash is seamlessly integrated into the current one. this structure not only ensures data integrity but also enhances the transparency and auditability of the network. transition to block streams when transitioning from the existing hedera record stream to block streams, the hash of the final record file will be included as input to the first block. this ensures cryptographic continuity between the existing record stream and the new block stream format. impacts on mirror nodes the mirror node software ensures a smooth transition from records to block streams and block nodes, offering an intuitive and straightforward upgrade process for operators. additionally, the introduction of block streams brings significant features and benefits to mirror node operators and consumers, including the following: 1. aggregated signature – less cost, less latency currently, each node generates a v6 record stream and a signature file for verification. mirror nodes must download signature files from a strong minority (1/3 of consensus stake) along with the record file, which makes frequent cloud storage access expensive. blocks now include a single aggregated signature to cut costs and simplify the process. 2. file naming and retrieval – less cost record stream files are named after the first transaction's consensus timestamp, forcing mirror nodes to perform costly list operations on cloud storage to find new record files. the new block streams use sequential block numbers, removing the need for these operations. 3. sidecar inclusion – lower complexity and processing in record streams, sidecar files store extra data—like smart contract logs—separately from the main record stream. block streams integrate this sidecar data into a unified stream, simplifying data management for mirror node operators. 4. reduced egress currently, records streams are stored in cloud buckets, incurring egress charges for requesters. with the introduction of block nodes, mirror node operators have the flexibility to select their preferred block node, offering greater control over geolocation and reducing egress costs. final thoughts block streams mark a significant step in hedera's evolution, providing a powerful new way to leverage network data for verification, transparency, and innovation. as we roll out this feature, we encourage your feedback and collaboration to explore the full potential of block streams to transform how we interact with and verify blockchain data. together, we’re paving the way for a more connected, transparent, and efficient decentralized future. starting with release 0.56, developers can access block streams, which will contain full mainnet blocks, including all data, except for the block proof, which will be mocked for development purposes. the blocks will be published to the google cloud service (gcs) utilized by hedera's record stream, adhering to the following structure: gs://hedera-mainnet-streams/block-preview/mainnet/0/3/000[..].blk.gz for more information, please visit: hedera documentation share this back to blog what is grpc, grpc-web, and proxies? ed marquez pragmatic blockchain design patterns – integrating blockchain into business processes michiel mulders zero cost ethereumtransaction on success: hedera's new fee model for relay operators oliver thorn hedera adopts chainlink standard for cross-chain interoperability to accelerate ecosystem adoption hedera team hedera developer highlights march 2025 michiel mulders hedera release cycle overview ed marquez view all posts sign up for the newsletter connect with us transparency open source audits & standards sustainability commitment carbon offsets governance hedera council public policy treasury management meeting minutes llc agreement node requirements community events meetups hbar telegram developer discord twitter community support faq network status developer discord stackoverflow brand brand guidelines built on hedera logo hedera store about team partners journey roadmap careers contact general inquiry public relations © 2018-2025 hedera hashgraph, llc. all trademarks and company names are the property of their respective owners. all rights in the deutsche telekom mark are protected by deutsche telekom ag. all rights reserved. hedera uses the third party marks with permission. terms of use | privacy policy erc-2615: non-fungible token with mortgage and rental functions ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2615: non-fungible token with mortgage and rental functions authors kohshi shiba created 2020-04-25 discussion link https://github.com/ethereum/eips/issues/2616 requires eip-165, eip-721 table of contents simple summary abstract motivation specification erc-2615 interface erc-2615 receiver erc-2615 extensions how rentals and mortgages work mortgage functions rental functions rationale no security lockup for rentals no ownership escrow when taking out a mortgage easy integration no money/token transactions within tokens backward compatibility test cases implementation security considerations copyright simple summary this standard proposes an extension to erc721 non-fungible tokens (nfts) to support rental and mortgage functions. these functions are necessary for nfts to emulate real property, just like those in the real world. abstract this standard is an extension of erc721. it proposes additional roles, the right of tenants to enable rentals, and the right of lien. with erc2615, nft owners will be able to rent out their nfts and take out a mortgage by collateralizing their nfts. for example, this standard can apply to: virtual items (in-game assets, virtual artwork, etc.) physical items (houses, automobiles, etc.) intellectual property rights dao membership tokens nft developers are also able to easily integrate erc2615 since it is fully backwards-compatible with the erc721 standard. one notable point is that the person who has the right to use an application is not the owner but the user (i.e. tenant). application developers must implement this specification into their applications. motivation it has been challenging to implement rental and mortgage functions with the erc721 standard because it only has one role defined (which is the owner). currently, a security deposit is needed for trustless renting with erc721, and ownership lockup within a contract is necessary whenever one chooses to mortgage their erc721 property. the tracking and facilitation of these relationships must be done separately from the erc721 standard. this proposal eliminates these requirements by integrating basic rights of tenantship and liens. by standardizing these functions, developers can more easily integrate rental and mortgage functions for their applications. specification this standard proposes three user roles: the lien holder, the owner, and the user. their rights are as follows: a lien holder has the right to: transfer the owner role transfer the user role an owner has the right to: transfer the owner role transfer the user role a user has the right to: transfer the user role erc-2615 interface event transferuser(address indexed from, address indexed to, uint256 indexed itemid, address operator); event approvalforuser(address indexed user, address indexed approved, uint256 itemid); event transferowner(address indexed from, address indexed to, uint256 indexed itemid, address operator); event approvalforowner(address indexed owner, address indexed approved, uint256 itemid); event approvalforall(address indexed owner, address indexed operator, bool approved); event lienapproval(address indexed to, uint256 indexed itemid); event tenantrightapproval(address indexed to, uint256 indexed itemid); event lienset(address indexed to, uint256 indexed itemid, bool status); event tenantrightset(address indexed to, uint256 indexed itemid,bool status); function balanceofowner(address owner) public view returns (uint256); function balanceofuser(address user) public view returns (uint256); function userof(uint256 itemid) public view returns (address); function ownerof(uint256 itemid) public view returns (address); function safetransferowner(address from, address to, uint256 itemid) public; function safetransferowner(address from, address to, uint256 itemid, bytes memory data) public; function safetransferuser(address from, address to, uint256 itemid) public; function safetransferuser(address from, address to, uint256 itemid, bytes memory data) public; function approveforowner(address to, uint256 itemid) public; function getapprovedforowner(uint256 itemid) public view returns (address); function approveforuser(address to, uint256 itemid) public; function getapprovedforuser(uint256 itemid) public view returns (address); function setapprovalforall(address operator, bool approved) public; function isapprovedforall(address requester, address operator) public view returns (bool); function approvelien(address to, uint256 itemid) public; function getapprovedlien(uint256 itemid) public view returns (address); function setlien(uint256 itemid) public; function getcurrentlien(uint256 itemid) public view returns (address); function revokelien(uint256 itemid) public; function approvetenantright(address to, uint256 itemid) public; function getapprovedtenantright(uint256 itemid) public view returns (address); function settenantright(uint256 itemid) public; function getcurrenttenantright(uint256 itemid) public view returns (address); function revoketenantright(uint256 itemid) public; erc-2615 receiver function onercxreceived(address operator, address from, uint256 itemid, uint256 layer, bytes memory data) public returns(bytes4); erc-2615 extensions extensions here are provided to help developers build with this standard. 1. erc721 compatible functions this extension makes this standard compatible with erc721. by adding the following functions, developers can take advantage of the existing tools for erc721. transfer functions in this extension will transfer both the owner and user roles when the tenant right has not been set. conversely, when the tenant right has been set, only the owner role will be transferred. function balanceof(address owner) public view returns (uint256) function ownerof(uint256 itemid) public view returns (address) function approve(address to, uint256 itemid) public function getapproved(uint256 itemid) public view returns (address) function transferfrom(address from, address to, uint256 itemid) public function safetransferfrom(address from, address to, uint256 itemid) public function safetransferfrom(address from, address to, uint256 itemid, bytes memory data) pubic 2. enumerable this extension is analogous to the enumerable extension of the erc721 standard. function totalnumberofitems() public view returns (uint256); function itemofownerbyindex(address owner, uint256 index, uint256 layer)public view returns (uint256 itemid); function itembyindex(uint256 index) public view returns (uint256); 3. metadata this extension is analogous to the metadata extension of the erc721 standard. function itemuri(uint256 itemid) public view returns (string memory); function name() external view returns (string memory); function symbol() external view returns (string memory); how rentals and mortgages work this standard does not deal with token or value transfer. other logic (outside the scope of this standard) must be used to orchestrate these transfers and to implement validation of payment. mortgage functions the following diagram demonstrates the mortgaging functionality. suppose alice owns an nft and wants to take out a mortgage, and bob wants to earn interest by lending tokens to alice. alice approves the setting of a lien for the nft alice owns. alice sends a loan request to the mortgage contract. bob fills the loan request and transfers tokens to the mortgage contract. the lien is then set on the nft by the mortgage contract. alice can now withdraw the borrowed tokens from the mortgage contract. alice registers repayment (anyone can pay the repayment). bob can finish the agreement if the agreement period ends and the agreement is kept (i.e. repayment is paid without delay). bob can revoke the agreement if the agreement is breached (e.g. repayment is not paid on time) and execute the lien and take over the ownership of the nft. rental functions the following diagram demonstrates the rental functionality. suppose alice owns nfts and wants to rent out a nft, and bob wants to lease a nft. alice approves the setting of a tenant-right for the nft alice owns. alice sends a rental listing to the rental contract. bob fills the rental request, and the right to use the nft is transferred to bob. at the same time, the tenant-right is set, and alice becomes not able to transfer the right to use the nft. bob registers rent (anyone can pay the rent). alice can withdraw the rent from the rental contract. alice can finish the agreement if the agreement period has ended and the agreement is kept (i.e. rent is paid without delay). alice can revoke the agreement if the agreement is breached (e.g. rent is not paid on time) and revoke the tenant-right and take over the right to use the nft. rationale there have been some attempts to achieve rentals or mortgages with erc721. however, as i noted before, it has been challenging to achieve. i will explain the reasons and advantages of this standard below. no security lockup for rentals to achieve trustless rental of nfts with erc721, it has been necessary to deposit funds as security. this is required to prevent malicious activity from tenants, as it is impossible to take back ownership once it is transferred. with this standard, security deposits are no longer needed since the standard natively supports rental and tenantship functions. no ownership escrow when taking out a mortgage in order to take out a mortgage on nfts, it has been necessary to transfer the nfts to a contract as collateral. this is required to prevent the potential default risk of the mortgage. however, secured collateral with erc721 hurts the utility of the nft. since most nft applications provide services to the canonical owner of a nft, the nft essentially cannot be utilized under escrow. with erc2615, it is possible to collateralize nfts and use them at the same time. easy integration because of the above reasons, a great deal of effort is required to implement rental and mortgage functions with erc721. adopting this standard is a much easier way to integrate rental and mortgage functionality. no money/token transactions within tokens a nft itself does not handle lending or rental functions directly. this standard is open-source, and there is no platform lockup. developers can integrate it without having to worry about those risks. backward compatibility as mentioned in the specifications section, this standard can be fully erc721 compatible by adding an extension function set. in addition, new functions introduced in this standard have many similarities with the existing functions in erc721. this allows developers to easily adopt the standard quickly. test cases when running the tests, you need to create a test network with ganache-cli: ganache-cli -a 15 --gaslimit=0x1fffffffffffff -e 1000000000 and then run the tests using truffle: truffle test -e development powered by truffle and openzeppelin test helper. implementation github reposotory. security considerations since the external contract will control lien or tenant rights, flaws within the external contract directly lead to the standard’s unexpected behavior. copyright copyright and related rights waived via cc0. citation please cite this document as: kohshi shiba , "erc-2615: non-fungible token with mortgage and rental functions [draft]," ethereum improvement proposals, no. 2615, april 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2615. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1337: subscriptions on the blockchain ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1337: subscriptions on the blockchain authors kevin owocki , andrew redden , scott burke , kevin seagraves , luka kacil , štefan šimec , piotr kosiński (@kosecki123), ankit raj , john griffin , nathan creswell created 2018-08-01 discussion link https://ethereum-magicians.org/t/eip-1337-subscriptions-on-the-blockchain/4422 requires eip-20, eip-165 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary monthly subscriptions are a key monetization channel for legacy web, and arguably they are the most healthy monetization channel for businesses on the legacy web (especially when compared to ad/surveillance) based models. they are arguably more healthy than a token based economic system (depending upon the vesting model of the ico) because for a user: you don’t have to read a complex whitepaper to use a dapps utility (as opposed to utility tokens) you don’t have to understand the founder’s vesting schedules you can cancel anytime for a service provider: since you know your subscriber numbers, churn numbers, conversion rate, you get consistent cash flow, and accurate projections you get to focus on making your customers happy enables you to remove speculators from your ecosystem for these reasons, we think it’s imperative to create a standard way to do ‘subscriptions’ on ethereum. abstract to enable replay-able transactions users sign a concatenated bytes hash that is composed of the input data needed to execute the transaction. this data is stored off chain by the recipient of the payment and is transmitted to the customers smart contract for execution alongside a provided signature. motivation recurring payments are the bedrock of sass and countless other businesses, a robust specification for defining this interaction will enable a broad spectrum of revenue generation and business models. specification enum contract eip-1337 contracts should be compiled with a contract that references all the enumerations that are required for operation /// @title enum collection of enums /// original concept from richard meissner gnosis safe contracts contract enum { enum operation { call, delegatecall, create, erc20, erc20approve } enum subscriptionstatus { active, paused, cancelled, expired } enum period { init, day, week, month } } eip-165 eip-1337 compliant contracts support eip-165 announcing what interfaces they support interface erc165 { /** * @notice query if a contract implements an interface * @param interfaceid the interface identifier, as specified in erc-165 * @dev interface identification is specified in erc-165. this function * uses less than 30,000 gas. * @return `true` if the contract implements `interfaceid` and * `interfaceid` is not 0xffffffff, `false` otherwise **/ function supportsinterface(bytes4 interfaceid) external view returns (bool); } public view functions isvalidsubscription /** @dev checks if the subscription is valid. * @param bytes subscriptionhash is the identifier of the customer's subscription with its relevant details. * @return success is the result of whether the subscription is valid or not. **/ function isvalidsubscription( uint256 subscriptionhash ) public view returns ( bool success ) getsubscriptionstatus /** @dev returns the value of the subscription * @param bytes subscriptionhash is the identifier of the customer's subscription with its relevant details. * @return status is the enumerated status of the current subscription, 0 expired, 1 active, 2 paused, 3 cancelled **/ function getsubscriptionstatus( uint256 subscriptionhash ) public view returns ( uint256 status, uint256 nextwithdraw ) getsubscriptionhash /** @dev returns the hash of cocatenated inputs to the address of the contract holding the logic., * the owner would sign this hash and then provide it to the party for execution at a later date, * this could be viewed like a cheque, with the exception that unless you specifically * capture the hash on chain a valid signature will be executable at a later date, capturing the hash lets you modify the status to cancel or expire it. * @param address recipient the address of the person who is getting the funds. * @param uint256 value the value of the transaction * @param bytes data the data the user is agreeing to * @param uint256 txgas the cost of executing one of these transactions in gas(probably safe to pad this) * @param uint256 datagas the cost of executing the data portion of the transaction(delegate calls etc) * @param uint 256 gasprice the agreed upon gas cost of execution of this subscription(cost incurment is up to implementation, ie, sender or receiver) * @param address gastoken address of the token in which gas will be compensated by, address(0) is eth, only works in the case of an enscrow implementation) * @param bytes meta dynamic bytes array with 4 slots, 2 required, 2 optional // address refundaddress / uint256 period / uint256 offchainid / uint256 expiration (uinx timestamp) * @return bytes32, return the hash input arguments concatenated to the address of the contract that holds the logic. **/ function getsubscriptionhash( address recipient, uint256 value, bytes data, enum.operation operation, uint256 txgas, uint256 datagas, uint256 gasprice, address gastoken, bytes meta ) public view returns ( bytes32 subscriptionhash ) getmodifystatushash /** @dev returns the hash of concatenated inputs that the owners user would sign with their public keys * @param address recipient the address of the person who is getting the funds. * @param uint256 value the value of the transaction * @return bytes32 returns the hash of concatenated inputs with the address of the contract holding the subscription hash **/ function getmodifystatushash( bytes32 subscriptionhash enum.subscriptionstatus status ) public view returns ( bytes32 modifystatushash ) public functions modifystatus /** @dev modifys the current subscription status * @param uint256 subscriptionhash is the identifier of the customer's subscription with its relevant details. * @param enum.subscriptionstatus status the new status of the subscription * @param bytes signatures of the requested method being called * @return success is the result of the subscription being paused **/ function modifystatus( uint256 subscriptionhash, enum.subscriptionstatus status, bytes signatures ) public returns ( bool success ) executesubscription /** @dev returns the hash of cocatenated inputs to the address of the contract holding the logic., * the owner would sign this hash and then provide it to the party for execution at a later date, * this could be viewed like a cheque, with the exception that unless you specifically * capture the hash on chain a valid signature will be executable at a later date, capturing the hash lets you modify the status to cancel or expire it. * @param address recipient the address of the person who is getting the funds. * @param uint256 value the value of the transaction * @param bytes data the data the user is agreeing to * @param uint256 txgas the cost of executing one of these transactions in gas(probably safe to pad this) * @param uint256 datagas the cost of executing the data portion of the transaction(delegate calls etc) * @param uint 256 gasprice the agreed upon gas cost of execution of this subscription(cost incurment is up to implementation, ie, sender or receiver) * @param address gastoken address of the token in which gas will be compensated by, address(0) is eth, only works in the case of an enscrow implementation) * @param bytes meta dynamic bytes array with 4 slots, 2 required, 2 optional // address refundaddress / uint256 period / uint256 offchainid / uint256 expiration (uinx timestamp) * @param bytes signatures signatures concatenated that have signed the inputs as proof of valid execution * @return bool success something to note that a failed execution will still pay the issuer of the transaction for their gas costs. **/ function executesubscription( address to, uint256 value, bytes data, enum.operation operation, uint256 txgas, uint256 datagas, uint256 gasprice, address gastoken, bytes meta, bytes signatures ) public returns ( bool success ) rationale merchants who accept credit-cards do so by storing a token that is retrieved from a third party processor(stripe, paypal, etc), this token is used to grant access to pull payment from the cx’s credit card provider and move funds to the merchant account. having users sign input data acts in a similliar fashion and enables that merchant to store the signature of the concatenated bytes hash and input data used to generate the hash and pass them off to the contract holding the subscription logic, thus enabling a workflow that is similliar to what exists in the present day legacy web. backwards compatibility n/a test cases tbd implementation tbd copyright copyright and related rights waived via cc0. citation please cite this document as: kevin owocki , andrew redden , scott burke , kevin seagraves , luka kacil , štefan šimec , piotr kosiński (@kosecki123), ankit raj , john griffin , nathan creswell , "erc-1337: subscriptions on the blockchain [draft]," ethereum improvement proposals, no. 1337, august 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1337. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6604: abstract token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-6604: abstract token move tokens onand off-chain as desired, enabling zero-cost minting while preserving on-chain composability authors chris walker (@cr-walker) created 2023-03-03 discussion link https://ethereum-magicians.org/t/draft-eip-abstract-token-standard/13152 requires eip-20, eip-165, eip-721, eip-1155 table of contents abstract motivation specification data types methods events application to existing token standards abstract erc-20 abstract erc-721 abstract erc-1155 rationale meta format proof format backwards compatibility reference implementation security considerations message loss authorizing reification non-owner (de)reification abstract token bridge double spend copyright abstract abstract tokens provide a standard interface to: mint tokens off-chain as messages reify tokens on-chain via smart contract dereify tokens back into messages abstract tokens can comply with existing standards like erc-20, erc-721, and erc-1155. the standard allows wallets and other applications to better handle potential tokens before any consensus-dependent events occur on-chain. motivation abstract tokens enable zero-cost token minting, facilitating high-volume applications by allowing token holders to reify tokens (place the tokens on-chain) as desired. example use cases: airdrops poaps / receipts identity / access credentials merkle trees are often used for large token distributions to spread mint/claim costs to participants, but they require participants to provide a markle proof when claiming tokens. this standard aims to improve the claims proces for similar distributions: generic: compatible with merkle trees, digital signatures, or other eligibility proofs legible: users can query an abstract token contract to understand their potential tokens (e.g. token id, quantity, or uri) contained: users do not need to understand the proof mechanism used by the particular token implementation contract 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. data types token messages a token message defines one or more tokens along with the context needed to reify the token(s) using a smart contract. chainid & implementation: set the domain of the token message to a specific chain and contract: this is where the token can be reified owner: the address that owns the tokens defined in the messages when reified meta: implementation-specific context necessary to reify the defined token(s), such as id, amount, or uri. proof: implementation-specific authorization to reify the defined token(s). nonce: counter that may be incremented when multiple otherwise-identical abstract token messages are needed struct abstracttokenmessage { uint256 chainid; address implementation; address owner; bytes meta; uint256 nonce; bytes proof; } message status a message status may be defined for every (abstract token contract, abstract token message) pair. invalid: the contract cannot interact with the message valid: the contract can interact with the message used: the contract has already interacted with the message enum abstracttokenmessagestatus { invalid, valid, used } methods reify moves token(s) from a message to a contract function reify(abstracttokenmessage calldata message) external; the token contract must reify a valid token message. reification must be idempotent: a particular token message may be used to reify tokens at most once. calling reify with an already used token message may succeed or revert. status returns the status of a particular message function status(abstracttokenmessage calldata message) external view returns (abstracttokenmessagestatus status); dereify moves token(s) from a contract to a message intended for another contract and/or chain. function dereify(abstracttokenmessage calldata message) external; optional allows tokens to be moved between contracts and/or chains by dereifying them from one context and reifying them in another. dereification must be idempotent: a particular token message must be used to dereify tokens at most once. if implemented, dereification: must burn the exact tokens from the holder as defined in the token message must not dereify token messages scoped to the same contract and chain. may succeed or revert if the token message is already used. must emit the reify event on only the first reify call with a specific token message id return the id of token(s) defined in a token message. function id(abstracttokenmessage calldata message) external view returns (uint256); optional abstract token contracts without a well-defined token id (e.g. erc-20) may return 0 or not implement this method. amount return the amount of token(s) defined in a token message. function amount(abstracttokenmessage calldata message) external view returns (uint256); optional abstract token contracts without a well-defined token amount (e.g. erc-721) may return 0 or not implement this method. uri return the amount of token(s) defined in a token message. function uri(abstracttokenmessage calldata message) external view returns (string memory); optional abstract token contracts without a well-defined uri (e.g. erc-20) may return "" or not implement this method. supportsinterface all abstract token contracts must support erc-165 and include the abstract token interface id in their supported interfaces. events reify the reify event must be emitted when a token message is reified into tokens event reify(abstracttokenmessage); dereify the dereify event must be emitted when tokens are dereified into a message event dereify(abstracttokenmessage); application to existing token standards abstract tokens compatible with existing token standards must overload existing token transfer functions to allow transfers from abstract token messages. abstract erc-20 interface iabstracterc20 is iabstracttoken, ierc20, ierc165 { // reify the message and then transfer tokens function transfer( address to, uint256 amount, abstracttokenmessage calldata message ) external returns (bool); // reify the message and then transferfrom tokens function transferfrom( address from, address to, uint256 amount, abstracttokenmessage calldata message ) external returns (bool); } abstract erc-721 interface iabstracterc721 is iabstracttoken, ierc721 { function safetransferfrom( address from, address to, uint256 tokenid, bytes calldata _data, abstracttokenmessage calldata message ) external; function transferfrom( address from, address to, uint256 tokenid, abstracttokenmessage calldata message ) external; } abstract erc-1155 interface iabstracterc1155 is iabstracttoken, ierc1155 { function safetransferfrom( address from, address to, uint256 id, uint256 amount, bytes calldata data, abstracttokenmessage calldata message ) external; function safebatchtransferfrom( address from, address to, uint256[] calldata ids, uint256[] calldata amounts, bytes calldata data, abstracttokenmessage[] calldata messages ) external; } rationale meta format the abstract token message meta field is simply a byte array to preserve the widest possible accesibility. applications handling abstract tokens can interact with the implementation contract for token metadata rather than parsing this field, so legibility is of secondary importance a byte array can be decoded as a struct and checked for errors within the implementation contract future token standards will include unpredictable metadata proof format similar considerations went into defining the proof field as a plain byte array: the contents of this field may vary, e.g. an array of bytes32 merkle tree nodes or a 65 byte signature. a byte array handles all potential use cases at the expense of increased message size. backwards compatibility no backward compatibility issues found. reference implementation see here. security considerations several concerns are highlighted. message loss because token messages are not held on-chain, loss of the message may result in loss of the token. applications that issue abstract tokens to their users can store the messages themselves, but ideally users would be able to store and interact with abstract token messages within their crypto wallets. authorizing reification token messages may only be reified if they include a validity proof. while the proof mechanism itself is out of scope for this standard, those designing proof mechanisms should consider: does total supply need to audited on-chain and/or off-chain? does the mechanism require ongoing access to a secret (e.g. digital signature) or is it immutable (e.g. merkle proof)? is there any way for an attacker to prevent the reification of an otherwise valid token message? non-owner (de)reification can non-owners (de)reify a token message on behalf of the owner? pro: supporting apps should be able to handle this because once a valid message exists, the owner could (de)reify the message at any time con: if the token contract reverts upon (de)reification of a used message, an attacker could grief the owner by front-running the transaction abstract token bridge double spend abstract tokens could be used for a token-specific bridge: dereify the token from chain a to with message m reify the token on chain b with message m because the abstract token standard does not specify any cross-chain message passing, the abstract token contracts on chains a and b cannot know whether a (de)reification of message m has occurred on the other chain. a naive bridge would be subject to double spend attacks: an attacker requests bridging tokens they hold on chain a to chain b a bridging mechanism creates an abstract token message m the attacker reifies message m on chain b but does not dereify message m on chain a the attacker continues to use tokens some oracle mechanism is necessary to prevent the reification of message m on chain b until the corresponding tokens on chain a are dereified. copyright copyright and related rights waived via cc0. citation please cite this document as: chris walker (@cr-walker) , "erc-6604: abstract token [draft]," ethereum improvement proposals, no. 6604, march 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6604. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. ethereum messaging for the masses (including fathers) via infographic | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search ethereum messaging for the masses (including fathers) via infographic posted by anthony di iorio on june 21, 2015 research & development when i started evangelizing bitcoin and blockchain tech back in 2012 my dad was a hard sell. there was the common skepticism and typical counters of “what’s backing it?”, “what can be done with it?” and “what the heck is cryptography?" back then my pitch wasn’t refined and the learning tools had just not quite matured yet...but frankly, i think more of the reason he didn’t grasp it was that he just isn’t technical and doesn’t adopt early tech. i delicately persisted and he eventually came around. before the end of 2012 he had secured a nice stash of coins and as the price rose by many multiples i secured more and more of his ear for future opportunities that might arise. now he didn’t decide to buy bitcoins because he ended up understanding the technology, in fact, i’m still not sure years later if he understands much of the bitcoin nitty-gritty or has wrapped his head around the potential implications that blockchain technology provides. when ethereum came along, he most certainly didn’t understand the concept and why i decided to drop everything in late 2013 and risk sizable capital bootstrapping the project with my then co-founders vitalik, mihai, and charles, and eventually the rest of the founding team, as it exists today. bitcoin is complex to explain, ethereum takes it up a couple notches. it’s not rocket science but sure can seem like it to many people. unheard of terms like as smart contracts, smart property, or dapps can seem daunting to the masses. even terms or words becoming more common such as “cryptocurrency” or “distributed ledger system” can still be unfamiliar to many. let’s face it. this technology is not easy for the majority to grasp and the messaging needs continual refinement and crafting for this to change. rightly so, the majority of focus and current goal of ethereum is to get the tools into the hands of developers and to show them how they can create the products end users will eventually value. less time and resources have been spent explaining ethereum to end consumers, enterprise, and institutions. with weekly announcements of “blockchain integrations” (see nasdaq, ibm, honduran government and countless others) and friendly legislation proposals emerge from countries like canada, there’s obvious increased interest from many sectors and as more integration projects start hitting the news, more and more interest gets sparked from organizations not wanting to get left behind. explaining complex ideas so how do we get ethereum, and in general, complex ideas to the general public? well, whether it's a company trying to communicate new innovations to investors, or an educator teaching a challenging topic in a brief amount of time, the problem is how do you take an abundance of mostly technical information and effectively simplify and present if in an engaging and informative way? one answer is infographics. here are a few benefits of this medium infographics are more eye-catching than printed words since they usually combine images, colors and content that naturally draw the eye and appeal to those with shorter attention spans. infographics are extremely shareable around the web using embed code and are perfect for social network sharing if visually appealing with consistent colors, shapes. messages and logo they provide an effective means of brand awareness bellow is the concept of the first general infographic for ethereum designed for the masses. i’ll allow it to speak for itself and i welcome feedback and questions as to why we crafted the message the way we did or why certain terms or ideas were left out. please feel free to share this and help get the message around the web. this is the first of a few proposed infographics. the next one will focus more on ethereum use cases for various sectors, then one for the more technically inclined. i’m missing father’s day with my dad (and my brother's first fathers day) to be in switzerland on ethereum business. however i did see my dad this week and felt a certain accomplishment when after showing him the infographic he told me: “i finally have a clue what ethereum is and its potential. now what’s all this talk about bitcoin?” happy father’s day to all you fathers out there from ethereum anthony di iorio is a founder of ethereum and currently serves as a consultant and adviser for the project. he is president and founder of decentral and decentral consulting services, offering technology consultancy services that specialize in blockchain and decentralized technology integrations for enterprise, small business and start-ups. anthony is the cryptocurrency adviser at mars discovery district, organizes the toronto ethereum meetup group and dec_tech (decentralized technologies) events and will be lecturing this summer at the university of nicocia's masters program in digital currencies. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-6224: contracts dependencies registry ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-6224: contracts dependencies registry an interface for managing smart contracts with their dependencies. authors artem chystiakov (@arvolear) created 2022-12-27 discussion link https://ethereum-magicians.org/t/eip-6224-contracts-dependencies-registry/12316 requires eip-1967, eip-5750 table of contents abstract motivation specification contractsregistry dependant rationale contractsregistry rationale dependant rationale reference implementation security considerations contractsregistry security considerations dependant security considerations copyright abstract the eip standardizes the management of smart contracts within the decentralized application ecosystem. it enables protocols to become upgradeable and reduces their maintenance threshold. this eip additionally introduces a smart contract dependency injection mechanism to audit dependency usage, to aid larger composite projects. motivation in the ever-growing ethereum, projects tend to become more and more complex. modern protocols require portability and agility to satisfy customer needs by continuously delivering new features and staying on pace with the industry. however, the requirement is hard to achieve due to the immutable nature of blockchains and smart contracts. moreover, the increased complexity and continuous delivery bring bugs and entangle the dependencies between the contracts, making systems less supportable. applications that have a clear facade and transparency upon their dependencies are easier to develop and maintain. the given eip tries to solve the aforementioned problems by presenting two concepts: the contracts registry and the dependant. the advantages of using the provided pattern might be: structured smart contracts management via specialized contract. ad-hoc upgradeability provision. runtime smart contracts addition, removal, and substitution. dependency injection mechanism to keep smart contracts’ dependencies under control. 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. contractsregistry the contractsregistry must implement the following interface: pragma solidity ^0.8.0; interface icontractsregistry { /** * @notice required the event that is emitted when the contract gets added to the registry * @param name the name of the contract * @param contractaddress the address of the added contract * @param isproxy whether the added contract is a proxy */ event addedcontract(string name, address contractaddress, bool isproxy); /** * @notice required the event that is emitted when the contract get removed from the registry * @param name the name of the removed contract */ event removedcontract(string name); /** * @notice required the function that returns an associated contract by the name * @param name the name of the contract * @return the address of the contract */ function getcontract(string memory name) external view returns (address); /** * @notice optional the function that checks if a contract with a given name has been added * @param name the name of the contract * @return true if the contract is present in the registry */ function hascontract(string memory name) external view returns (bool); /** * @notice recommended the function that returns the admin of the added proxy contracts * @return the proxy admin address */ function getproxyupgrader() external view returns (address); /** * @notice recommended the function that returns an implementation of the given proxy contract * @param name the name of the contract * @return the implementation address */ function getimplementation(string memory name) external view returns (address); /** * @notice required the function that injects dependencies into the given contract. * must call the setdependencies() with address(this) and bytes("") as arguments on the substituted contract * @param name the name of the contract */ function injectdependencies(string memory name) external; /** * @notice required the function that injects dependencies into the given contract with extra data. * must call the setdependencies() with address(this) and given data as arguments on the substituted contract * @param name the name of the contract * @param data the extra context data */ function injectdependencieswithdata( string calldata name, bytes calldata data ) external; /** * @notice required the function that upgrades added proxy contract with a new implementation * @param name the name of the proxy contract * @param newimplementation the new implementation the proxy will be upgraded to * * it is the owner's responsibility to ensure the compatibility between implementations */ function upgradecontract(string memory name, address newimplementation) external; /** * @notice recommended the function that upgrades added proxy contract with a new implementation, providing data * @param name the name of the proxy contract * @param newimplementation the new implementation the proxy will be upgraded to * @param data the data that the new implementation will be called with. this can be an abi encoded function call * * it is the owner's responsibility to ensure the compatibility between implementations */ function upgradecontractandcall( string memory name, address newimplementation, bytes memory data ) external; /** * @notice required the function that adds pure (non-proxy) contracts to the contractsregistry. the contracts may either be * the ones the system does not have direct upgradeability control over or the ones that are not upgradeable by design * @param name the name to associate the contract with * @param contractaddress the address of the contract */ function addcontract(string memory name, address contractaddress) external; /** * @notice required the function that adds the contracts and deploys the transaprent proxy above them. * it may be used to add contract that the contractsregistry has to be able to upgrade * @param name the name to associate the contract with * @param contractaddress the address of the implementation */ function addproxycontract(string memory name, address contractaddress) external; /** * @notice recommended the function that adds an already deployed proxy to the contractsregistry. it may be used * when the system migrates to the new contractregistry. in that case, the new proxyupgrader must have the * credentials to upgrade the newly added proxies * @param name the name to associate the contract with * @param contractaddress the address of the proxy */ function justaddproxycontract(string memory name, address contractaddress) external; /** * @notice required the function to remove contracts from the contractsregistry * @param name the associated name with the contract */ function removecontract(string memory name) external; } the contractsregistry must deploy the proxyupgrader contract in the constructor that must be set as an admin of transparent proxies deployed via addproxycontract method. it must not be possible to add the zero address to the contractsregistry. the contractsregistry must use the idependant interface in the injectdependencies and injectdependencieswithdata methods. dependant the dependant contract is the one that depends on other contracts present in the system. in order to support dependency injection mechanism, the dependant contract must implement the following interface: pragma solidity ^0.8.0; interface idependant { /** * @notice the function that is called from the contractsregistry (or factory) to inject dependencies. * @param contractsregistry the registry to pull dependencies from * @param data the extra data that might provide additional application-specific context/behavior * * the dependant must perform a dependency injector access check to this method */ function setdependencies(address contractsregistry, bytes calldata data) external; /** * @notice the function that sets the new dependency injector. * @param injector the new dependency injector * * the dependant must perform a dependency injector access check to this method */ function setinjector(address injector) external; /** * @notice the function that gets the current dependency injector * @return the current dependency injector */ function getinjector() external view returns (address); } the dependant contract must pull its dependencies in the setdependencies method from the passed contractsregistry address. the dependant contract may store the dependency injector address in the special slot 0x3d1f25f1ac447e55e7fec744471c4dab1c6a2b6ffb897825f9ea3d2e8c9be583 (obtained as bytes32(uint256(keccak256("eip6224.dependant.slot")) 1)). rationale there are a few design decisions that have to be specified explicitly: contractsregistry rationale usage the extensions of this eip should add proper access control checks to the described non-view methods. the getcontract and getimplementation methods must revert if the nonexistent contracts are queried. the contractsregistry may be set behind the proxy to enable runtime addition of custom methods. applications may also leverage the pattern to develop custom tree-like contractsregistry data structures. contracts identifier the string contracts identifier is chosen over the uint256 and bytes32 to maintain code readability and reduce the human-error chances when interacting with the contractsregistry. being the topmost smart contract, it may be typical for the users to interact with it via block explorers or daos. clarity was prioritized over gas usage. proxy the transparent proxy is chosen over the uups proxy to hand the upgradeability responsibility to the contractsregistry itself. the extensions of this eip may use the proxy of their choice. dependant rationale dependencies the required dependencies must be set in the overridden setdependencies method, not in the constructor or initializer methods. the data parameter is provided to carry additional application-specific context. it may be used to extend the method’s behavior. injector only the injector must be able to call the setdependencies and setinjector methods. the initial injector will be a zero address, in that case, the call must not revert on access control checks. the setinjector function is made external to support the dependency injection mechanism for factory-made contracts. however, the method should be used with extra care. the injector address may be stored in the dedicated slot 0x3d1f25f1ac447e55e7fec744471c4dab1c6a2b6ffb897825f9ea3d2e8c9be583 to exclude the chances of storage collision. reference implementation 0xdistributedlab-solidity-library dev-modules provides a reference implementation. security considerations the described eip must be used with extra care as the loss/leakage of credentials to the contractsregistry leads to the application’s point of no return. the contractregistry is a cornerstone of the protocol, access must be granted to the trusted parties only. contractsregistry security considerations the non-view methods of contractsregistry contract must be overridden with proper access control checks. the contractsregistry does not perform any upgradeability checks between the proxy upgrades. it is the user’s responsibility to make sure that the new implementation is compatible with the old one. dependant security considerations the non-view methods of dependant contract must be overridden with proper access control checks. only the dependency injector must be able to call them. the dependant contract must set its dependency injector no later than the first call to the setdependencies function is made. that being said, it is possible to front-run the first dependency injection. copyright copyright and related rights waived via cc0. citation please cite this document as: artem chystiakov (@arvolear), "erc-6224: contracts dependencies registry [draft]," ethereum improvement proposals, no. 6224, december 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6224. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-152: add blake2 compression function `f` precompile ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-152: add blake2 compression function `f` precompile authors tjaden hess , matt luongo (@mhluongo), piotr dyraga (@pdyraga), james hancock (@madeoftin) created 2016-10-04 table of contents simple summary abstract motivation specification example usage in solidity gas costs and benchmarks rationale backwards compatibility test cases implementation references appendix benchmarks 12 rounds 1200 rounds 1 round copyright simple summary this eip will enable the blake2b hash function and other higher-round 64-bit blake2 variants to run cheaply on the evm, allowing easier interoperability between ethereum and zcash as well as other equihash-based pow coins. abstract this eip introduces a new precompiled contract which implements the compression function f used in the blake2 cryptographic hashing algorithm, for the purpose of allowing interoperability between the evm and zcash, as well as introducing more flexible cryptographic hash primitives to the evm. motivation besides being a useful cryptographic hash function and sha3 finalist, blake2 allows for efficient verification of the equihash pow used in zcash, making a btc relay style spv client possible on ethereum. a single verification of an equihash pow verification requires 512 iterations of the hash function, making verification of zcash block headers prohibitively expensive if a solidity implementation of blake2 is used. blake2b, the common 64-bit blake2 variant, is highly optimized and faster than md5 on modern processors. interoperability with zcash could enable contracts like trustless atomic swaps between the chains, which could provide a much needed aspect of privacy to the very public ethereum blockchain. specification we propose adding a precompiled contract at address 0x09 wrapping the blake2 f compression function. the precompile requires 6 inputs tightly encoded, taking exactly 213 bytes, as explained below. the encoded inputs are corresponding to the ones specified in the blake2 rfc section 3.2: rounds the number of rounds 32-bit unsigned big-endian word h the state vector 8 unsigned 64-bit little-endian words m the message block vector 16 unsigned 64-bit little-endian words t_0, t_1 offset counters 2 unsigned 64-bit little-endian words f the final block indicator flag 8-bit word [4 bytes for rounds][64 bytes for h][128 bytes for m][8 bytes for t_0][8 bytes for t_1][1 byte for f] the boolean f parameter is considered as true if set to 1. the boolean f parameter is considered as false if set to 0. all other values yield an invalid encoding of f error. the precompile should compute the f function as specified in the rfc and return the updated state vector h with unchanged encoding (little-endian). example usage in solidity the precompile can be wrapped easily in solidity to provide a more development-friendly interface to f. function f(uint32 rounds, bytes32[2] memory h, bytes32[4] memory m, bytes8[2] memory t, bool f) public view returns (bytes32[2] memory) { bytes32[2] memory output; bytes memory args = abi.encodepacked(rounds, h[0], h[1], m[0], m[1], m[2], m[3], t[0], t[1], f); assembly { if iszero(staticcall(not(0), 0x09, add(args, 32), 0xd5, output, 0x40)) { revert(0, 0) } } return output; } function callf() public view returns (bytes32[2] memory) { uint32 rounds = 12; bytes32[2] memory h; h[0] = hex"48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5"; h[1] = hex"d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b"; bytes32[4] memory m; m[0] = hex"6162630000000000000000000000000000000000000000000000000000000000"; m[1] = hex"0000000000000000000000000000000000000000000000000000000000000000"; m[2] = hex"0000000000000000000000000000000000000000000000000000000000000000"; m[3] = hex"0000000000000000000000000000000000000000000000000000000000000000"; bytes8[2] memory t; t[0] = hex"03000000"; t[1] = hex"00000000"; bool f = true; // expected output: // ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d1 // 7d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923 return f(rounds, h, m, t, f); } gas costs and benchmarks each operation will cost gfround * rounds gas, where gfround = 1. detailed benchmarks are presented in the benchmarks appendix section. rationale blake2 is an excellent candidate for precompilation. blake2 is heavily optimized for modern 64-bit cpus, specifically utilizing 24 and 63-bit rotations to allow parallelism through simd instructions and little-endian arithmetic. these characteristics provide exceptional speed on native cpus: 3.08 cycles per byte, or 1 gibibyte per second on an intel i5. in contrast, the big-endian 32 byte semantics of the evm are not conducive to efficient implementation of blake2, and thus the gas cost associated with computing the hash on the evm is disproportionate to the true cost of computing the function natively. an obvious implementation would be a direct blake2b hash function precompile. at first glance, a blake2b precompile satisfies most hashing and interoperability requirements on the evm. once we started digging in, however, it became clear that any blake2b implementation would need specific features and internal modifications based on different projects’ requirements and libraries. a thread with the zcash team makes the issue clear. the minimal thing that is necessary for a working zec-eth relay is an implementation of blake2b compression f in a precompile. a blake2b compression function f precompile would also suffice for the filecoin and handshake interop goals. a full blake2b precompile would suffice for a zec-eth relay, provided that the implementation provided the parts of the blake2 api that we need (personalization, maybe something else—i’m not sure). i’m not 100% certain if a full blake2b precompile would also suffice for the filecoin and handshake goals. it almost certainly could, provided that it supports all the api that they need. blake2s — whether the compression function f or the full hash — is only a nice-to-have for the purposes of a zec-eth relay. from this and other conversations with teams in the space, we believe we should focus first on the f precompile as a strictly necessary piece for interoperability projects. a blake2b precompile is a nice-to-have, and we support any efforts to add one– but it’s unclear whether complete requirements and a flexible api can be found in time for istanbul. implementation of only the core f compression function also allows substantial flexibility and extensibility while keeping changes at the protocol level to a minimum. this will allow functions like tree hashing, incremental hashing, and keyed, salted, and personalized hashing as well as variable length digests, none of which are currently available on the evm. backwards compatibility there is very little risk of breaking backwards-compatibility with this eip, the sole issue being if someone were to build a contract relying on the address at 0x09 being empty. the likelihood of this is low, and should specific instances arise, the address could be chosen to be any arbitrary value with negligible risk of collision. test cases test vector 0 input: (empty) output: error “input length for blake2 f precompile should be exactly 213 bytes” test vector 1 input: 00000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001 output: error “input length for blake2 f precompile should be exactly 213 bytes” test vector 2 input: 000000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001 output: error “input length for blake2 f precompile should be exactly 213 bytes” test vector 3 input: 0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000002 output: error “incorrect final block indicator flag” test vector 4 input: 0000000048c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001 output: 08c9bcf367e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d282e6ad7f520e511f6c3e2b8c68059b9442be0454267ce079217e1319cde05b test vector 5 input: 0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001 output: ba80a53f981c4d0d6a2797b69f12f6e94c212f14685ac4b74b12bb6fdbffa2d17d87c5392aab792dc252d5de4533cc9518d38aa8dbf1925ab92386edd4009923 test vector 6 input: 0000000c48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000000 output: 75ab69d3190a562c51aef8d88f1c2775876944407270c42c9844252c26d2875298743e7f6d5ea2f2d3e8d226039cd31b4e426ac4f2d3d666a610c2116fde4735 test vector 7 input: 0000000148c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001 output: b63a380cb2897d521994a85234ee2c181b5f844d2c624c002677e9703449d2fba551b3a8333bcdf5f2f7e08993d53923de3d64fcc68c034e717b9293fed7a421 test vector 8 input: ffffffff48c9bdf267e6096a3ba7ca8485ae67bb2bf894fe72f36e3cf1361d5f3af54fa5d182e6ad7f520e511f6c3e2b8c68059b6bbd41fbabd9831f79217e1319cde05b61626300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000300000000000000000000000000000001 output: fc59093aafa9ab43daae0e914c57635c5402d8e3d2130eb9b3cc181de7f0ecf9b22bf99a7815ce16419e200e01846e6b5df8cc7703041bbceb571de6631d2615 implementation an initial implementation of the f function in go, adapted from the standard library, can be found in our golang blake2 library fork. there’s also an implementation of the precompile in our fork of go-ethereum. references for reference, further discussion on this eip also occurred in the following prs and issues original issue ethereum magicians pr 2129 appendix benchmarks assuming ecrecover precompile is perfectly priced, we executed a set of benchmarks comparing blake2b f compression function precompile with ecrecover precompile. for benchmarks, we used 3.1 ghz intel core i7 64-bit machine. $ sysctl -n machdep.cpu.brand_string intel(r) core(tm) i7-7920hq cpu @ 3.10ghz 12 rounds an average gas price of f precompile call with 12 rounds compared to ecrecover should have been 6.74153 and it gives 0.5618 gas per round. name gascost time (ns) mgas/s gasprice for 10mgas/s gasprice for ecdsa eq ---------------------------------------- -------- --------------- -------- ---------------------- ----------------------precompiledecrecover/ 3000 152636 19.6546 1526.36 3000 precompiledblake2f/testvectors2bx_0 12 338 35.503 3.38 6.64326 precompiledblake2f/testvectors2bx_3 12 336 35.7143 3.36 6.60395 precompiledblake2f/testvectors2bx_70 12 362 33.1492 3.62 7.11497 precompiledblake2f/testvectors2bx_140 12 339 35.3982 3.39 6.66291 precompiledblake2f/testvectors2bx_230 12 339 35.3982 3.39 6.66291 precompiledblake2f/testvectors2bx_300 12 343 34.9854 3.43 6.74153 precompiledblake2f/testvectors2bx_370 12 336 35.7143 3.36 6.60395 precompiledblake2f/testvectors2bx_440 12 337 35.6083 3.37 6.6236 precompiledblake2f/testvectors2bx_510 12 345 34.7826 3.45 6.78084 precompiledblake2f/testvectors2bx_580 12 355 33.8028 3.55 6.97738 columns mgas/s shows what mgas per second was measured on that machine at that time gasprice for 10mgas/s shows what the gasprice should have been, in order to reach 10 mgas/second gasprice for ecdsa eq shows what the gasprice should have been, in order to have the same cost/cycle as ecrecover 1200 rounds an average gas price of f precompile call with 1200 rounds compared to ecrecover should have been 436.1288 and it gives 0.3634 gas per round. name gascost time (ns) mgas/s gasprice for 10mgas/s gasprice for ecdsa eq ---------------------------------------- -------- --------------- -------- ---------------------- ----------------------precompiledecrecover/ 3000 156152 19.212 1561.52 3000 precompiledblake2f/testvectors2bx_0 1200 22642 52.9989 226.42 434.999 precompiledblake2f/testvectors2bx_3 1200 22885 52.4361 228.85 439.668 precompiledblake2f/testvectors2bx_70 1200 22737 52.7774 227.37 436.824 precompiledblake2f/testvectors2bx_140 1200 22602 53.0926 226.02 434.231 precompiledblake2f/testvectors2bx_230 1200 22501 53.331 225.01 432.29 precompiledblake2f/testvectors2bx_300 1200 22435 53.4879 224.35 431.022 precompiledblake2f/testvectors2bx_370 1200 22901 52.3995 229.01 439.975 precompiledblake2f/testvectors2bx_440 1200 23134 51.8717 231.34 444.452 precompiledblake2f/testvectors2bx_510 1200 22608 53.0786 226.08 434.346 precompiledblake2f/testvectors2bx_580 1200 22563 53.1844 225.63 433.481 1 round an average gas price of f precompile call with 1 round compared to ecrecover should have been 2.431701. however, in this scenario the call cost would totally overshadow the dynamic cost anyway. name gascost time (ns) mgas/s gasprice for 10mgas/s gasprice for ecdsa eq ---------------------------------------- -------- --------------- --------- ---------------------- ----------------------precompiledecrecover/ 3000 157544 19.0423 1575.44 3000 precompiledblake2f/testvectors2bx_0 1 126 7.93651 1.26 2.39933 precompiledblake2f/testvectors2bx_3 1 127 7.87402 1.27 2.41837 precompiledblake2f/testvectors2bx_70 1 128 7.8125 1.28 2.43741 precompiledblake2f/testvectors2bx_140 1 125 8 1.25 2.38029 precompiledblake2f/testvectors2bx_230 1 128 7.8125 1.28 2.43741 precompiledblake2f/testvectors2bx_300 1 127 7.87402 1.27 2.41837 precompiledblake2f/testvectors2bx_370 1 131 7.63359 1.31 2.49454 precompiledblake2f/testvectors2bx_440 1 129 7.75194 1.29 2.45646 precompiledblake2f/testvectors2bx_510 1 125 8 1.25 2.38029 precompiledblake2f/testvectors2bx_580 1 131 7.63359 1.31 2.49454 copyright copyright and related rights waived via cc0. citation please cite this document as: tjaden hess , matt luongo (@mhluongo), piotr dyraga (@pdyraga), james hancock (@madeoftin), "eip-152: add blake2 compression function `f` precompile," ethereum improvement proposals, no. 152, october 2016. [online serial]. available: https://eips.ethereum.org/eips/eip-152. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. on transaction fees, and the fallacy of market-based solutions | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search on transaction fees, and the fallacy of market-based solutions posted by vitalik buterin on february 1, 2014 research & development of all the parts of the ethereum protocol, aside from the mining function the fee structure is perhaps the least set in stone. the current values, with one crypto operation taking 20 base fees, a new transaction taking 100 base fees, etc, are little more than semi-educated guesses, and harder data on exactly how much computational power a database read, an arithmetic operation and a hash actually take will certainly give us much better estimates on what exactly the ratios between the different computational fees should be. the other part of the question, that of exactly how much the base fee should be, is even more difficult to figure out; we have still not decided whether we want to target a certain block size, a certain usd-denominated level, or some combination of these factors, and it is very difficulty to say whether a base fee of 0.00001orabasefeeof0.00001 or a base fee of 0.00001orabasefeeof0.001 would be more appropriate. ultimately, what is becoming more and more clear to us is that some kind of flexible fee system, that allows consensus-based human intervention after the fact, would be best for the project. when many people coming from bitcoin see this problem, however, they wonder why we are having such a hard time with this issue when bitcoin already has a ready-made solution: make the fees voluntary and market-based. in the bitcoin protocol, there are no mandatory transaction fees; even an extremely large and computationally arduous transaction can get in with a zero fee, and it is up to the miners to determine what fees they require. the lower a transaction’s fee, the longer it takes for the transaction to find a miner that will let it in, and those who want faster confirmations can pay more. at some point, an equilibrium should be reached. problem solved. so why not here? the reality, is, however, is that in bitcoin the transaction fee problem is very far from “solved”. the system as described above already has a serious vulnerability: miners have to pay no fees, so a miner can choke the entire network with an extremely large block. in fact, this problem is so serious that satoshi close to fix it with the ugliest possible path: set a maximum block size limit of 1 mb, or 7 transactions per second. now, without the immensely hard-fought and politically laden debate that necessarily accompanies any “hard-forking” protocol change, bitcoin simply cannot organically adapt to handle anything more than the 7 tx/sec limit that satoshi originally placed. and that’s bitcoin. in ethereum, the issue is even more problematic due to turing-completeness. in bitcoin, one can construct a mathematical proof that a transaction n bytes long will not take more than k*n time to verify for some constant k. in ethereum, one can construct a transaction in less than 150 bytes that, absent fees, will run forever: [ to, value, [ push, 0, jmp ], v, r, s ] in case you do not understand that, it’s the equivalent of 10: do_nothing, 20: goto 10; an infinite loop. and as soon as a miner publishes a block that includes that transaction, the entire network will freeze. in fact, thanks to the well-known impossibility of the halting problem, it is not even possible to construct a filter to weed out infinite-looping scripts. thus, computational attacks on ethereum are trivial, and even more restrictions must be placed in order to ensure that ethereum remains a workable platform. but wait, you might say, why not just take the 1 mb limit, and convert it into a 1 million x base fee limit? one can even make the system more future-proof by replacing a hard cap with a floating cap of 100 times the moving average of the last 10000 blocks. at this point, we need to get deeper into the economics and try to understand what “market-based fees” are all about. crypto, meet pigou in general terms, an idealized market, or at least one specific subset of a market, can be defined as follows. there exist a set of sellers, s[1] ... s[n], who are interested in selling a particular resource, and where seller s[i] incurs a cost c[i] from giving up that resource. we can say c[1] < c[2] < ... < c[n] for simplicity. similarly, there exist some buyers, b[1] ... b[n], who are interested in gaining a particular resource and incur a gain g[i], where g[1] > g[2] > ... > g[n]. then, an order matching process happens as follows. first, one locates the last k where g[k] > c[k]. then, one picks a price between those two values, say at p = (g[k] + c[k])/2, and s[i] and b[i] make a trade, where s[i] gives the resource to b[i] and b[i] pays p to s[i]. all parties benefit, and the benefit is the maximum possible; if s[k+1] and b[k+1] also made a transaction, c[k+1] > v[k+1], so the transaction would actually have negative net value to society. fortunately, it is in everybody’s interest to make sure that they do not participate in unfavorable trades. the question is, is this kind of market the right model for bitcoin transactions? to answer this question, let us try to put all of the players into roles. the resource is the service of transaction processing, and the people benefitting from the resource, the transaction senders, are also the buyers paying transaction fees. so far, so good. the sellers are obvious the miners. but who is incurring the costs? here, things get tricky. for each individual transaction that a miner includes, the costs are borne not just by that miner, but by every single node in the entire network. the cost per transaction is tiny; a miner can process a transaction and include it in a block for less than 0.00001worthofelectricityanddatastorage.thereasonwhytransactionfeesneedtobehighisbecausethat0.00001 worth of electricity and data storage. the reason why transaction fees need to be high is because that 0.00001worthofelectricityanddatastorage.thereasonwhytransactionfeesneedtobehighisbecausethat0.00001 is being paid by thousands of nodes all around the world. it gets worse. suppose that the net cost to the network of processing a transaction is close to 0.05.intheory,evenifthecostsarenotbornebyexactlythesamepeoplewhosettheprices,aslongasthetransactionfeeiscloseto0.05. in theory, even if the costs are not borne by exactly the same people who set the prices, as long as the transaction fee is close to 0.05.intheory,evenifthecostsarenotbornebyexactlythesamepeoplewhosettheprices,aslongasthetransactionfeeiscloseto0.05 the system would still be in balance. but what is the equilibrium transaction fee going to be? right now, fees are around 0.09simplybecauseminersaretoolazytoswitch.butthen,inthefuture,whathappensoncefeesbecomealargershareofaminer’srevenueandminershavealargeincentivetotrytomaximizetheirtake?theobviousansweris,forasolominertheequilibriumtransactionfeeis0.09 simply because miners are too lazy to switch. but then, in the future, what happens once fees become a larger share of a miner’s revenue and miners have a large incentive to try to maximize their take? the obvious answer is, for a solo miner the equilibrium transaction fee is 0.09simplybecauseminersaretoolazytoswitch.butthen,inthefuture,whathappensoncefeesbecomealargershareofaminer’srevenueandminershavealargeincentivetotrytomaximizetheirtake?theobviousansweris,forasolominertheequilibriumtransactionfeeis0.00001. if a transaction with a fee of 0.00002comesin,andthemineraddsit,theminerwillhaveearnedaprofitof0.00002 comes in, and the miner adds it, the miner will have earned a profit of 0.00002comesin,andthemineraddsit,theminerwillhaveearnedaprofitof0.00001, and the remaining $0.04999 worth of costs will be paid by the rest of the network together – a cryptographic tragedy of the commons. now, suppose that the mining ecosystem is more oligarchic, with one pool controlling 25% of all mining power. what are the incentives then? here, it gets more tricky. the mining pool can actually choose to set its minimum fee higher, perhaps at 0.001.thismayseemlikethepoolisforgoingprofitopportunitiesbetween0.001. this may seem like the pool is forgoing profit opportunities between 0.001.thismayseemlikethepoolisforgoingprofitopportunitiesbetween0.00001 and 0.00099,butwhatisalsohappeningisthatmanyofthetransactionsenderswhowereaddingbetween0.00099, but what is also happening is that many of the transaction senders who were adding between 0.00099,butwhatisalsohappeningisthatmanyofthetransactionsenderswhowereaddingbetween0.00001 and $0.00099 before now have the incentive to increase their fees to make sure this pool confirms their transactions – otherwise, they would need to wait an average of 3.3 minutes longer. thus, the fewer miners there are, the higher fees go – even thought a reduced number of miners actually means a lower network cost of processing all transactions. from the above discussion, what should become painfully clear is that transaction processing simply is not a market, and therefore trying to apply market-like mechanisms to it is an exercise in random guessing at best, and a scalability disaster at worst. so what are the alternatives? the economically ideal solution is one that has often been brought up in the context of global warming, perhaps the largest geopolitical tragedy of the commons scenario in the modern world: pigovian taxes. price setting without a market the way a pigovian tax works is simple. through some mechanism, the total net cost of consuming a certain quantity of a common resource (eg. network computation, air purity) is calculated. then, everyone who consumes that resource is required to pay that cost for every unit of the resource that they consume (or for every unit of pollution that they emit). the challenge in pigovian taxation, however, is twofold. first, who gets the revenue? second, and more importantly, there is no way to opt out of pollution, and thus no way for the market to extract people’s preferences about how much they would need to gain in order to suffer a given dose of pollution; thus, how do we set the price? in general, there are three ways of solving this problem: philosopher kings set the price, and disappear as the price is set in stone forever. philosopher kings maintain active control over the price. some kind of democratic mechanism there is also a fourth way, some kind of market mechanism which randomly doles out extra pollution to certain groups and attempts to measure the extent to which people (or network nodes in the context of a crytocurrency) are willing to go to avoid that pollution; this approach is interesting but heavily underexplored, and i will not attempt to examine it at this point in time. our initial strategy was (1). ripple’s strategy is (2). now, we are increasingly looking to (3). but how would (3) be implemented? fortunately, cryptocurrency is all about democratic consensus, and every cryptocurrency already has at least two forms of consensus baked in: proof of work and proof of stake. i will show two very simple protocols for doing this right now: proof of work protocol if you mine a block, you have the right to set a value in the “extra data field”, which can be anywhere from 0-32 bytes (this is already in the protocol) if the first byte of this data is 0, nothing happens if the first byte of this data is 1, we set block.basefee = block.basefee + floor(block.basefee / 65536) if the first byte of this data is 255, we set block.basefee = block.basefee floor(block.basefee / 65536) proof of stake protocol after each block, calculate h = sha256(block.parenthash + address) * block.address_balance(address)for each address if h > 2^256 / difficulty, where difficulty is a set constant, that address can sign either 1, 0 or 255 and create a signed object of the form [ val, v, r, s ] the miner can then include that object in the block header, giving the miner and the stakeholder some miniscule reward. if the data is 1, we set block.basefee = block.basefee + floor(block.basefee / 65536) if the data is 255, we set block.basefee = block.basefee floor(block.basefee / 65536) the two protocols are functionally close to identical; the only difference is that in the proof of work protocol miners decide on the basefee and in the proof of stake protocol ether holders do. the question is, do miners and ether holders have their incentives aligned to set the fee fairly? if transaction fees go to miners, then miners clearly do not. however, if transaction fees are burned, and thus their value goes to all ether holder proportionately through reduced inflation, then perhaps they do. miners and ether holders both want to see the value of their ether go up, so they want to set a fee that makes the network more useful, both in terms of not making it prohibitively expensive to make transactions and in terms of not setting a high computational load. thus, in theory, assuming rational actors, we will have fees that are at least somewhat reasonable. is there a reason to go one way or the other in terms of miners versus ether holders? perhaps there is. miners have the incentive to see the value of ether go as high as possible in the short term, but perhaps not so much in the long term, since a prolonged rise eventually brings competition which cancels out the miners’ increased profit. thus, miners might end up adopting a looser policy that imposes higher costs (eg. data storage) on miners far down the line. ether holders, on the other hand, seem to have a longer term interest. on the other hand, miners are somewhat “locked in” to mining ether specifically, especially if semi-specialized or specialized hardware gets involved; ether holders, on the other hand, can easily hop from one market to the other. furthermore, miners are less anonymous than ether holders. thus, the issue is not clear cut; if transaction fees are burned one can go either way. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-2333: bls12-381 key generation ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2333: bls12-381 key generation authors carl beekhuizen created 2019-09-30 discussion link https://github.com/ethereum/eips/issues/2337 table of contents simple summary abstract a note on purpose motivation deficiencies of the existing mechanism establishing a multi-chain standard early on a post-quantum backup specification version specification the tree structure key derivation derive_child_sk derive_master_sk rationale lamport signatures sha256 hkdf_mod_r() only using hardened keys backwards compatibility test cases test case 0 test case 1 test case 2 test case 3 test vector with intermediate values implementation copyright simple summary this eip is a method based on a tree structure for deriving bls private keys from a single source of entropy while providing a post-quantum cryptographic fallback for each key. abstract this standard is a method for deriving a tree-hierarchy of bls12-381 keys based on an entropy seed. starting with the aforementioned seed, a tree of keys is built out using only the parent node’s private key and the index of the desired child. this allows for a practically limitless number of keys to be derived for many different purposes while only requiring knowledge of a single ancestor key in the tree. this allows for keys, or families thereof, to be provisioned for different purposes by further standards. in addition to the above, this method of deriving keys provides an emergency backup signature scheme that is resistant to quantum computers for in the event that bls12-381 is ever deemed insecure. a note on purpose this specification is designed not only to be an ethereum 2.0 standard, but one that is adopted by the wider community who have adopted bls signatures over bls12-381. it is therefore important also to consider the needs of the wider industry along with those specific to ethereum. as a part of these considerations, it is the intention of the author that this standard eventually migrate to a more neutral repository in the future. motivation deficiencies of the existing mechanism the curve bls12-381 used for bls signatures within ethereum 2.0 (alongside many other projects) mandates a new key derivation scheme. the most commonly used scheme for key derivation within ethereum 1.x is bip32 (also known as hd derivation) which deems keys greater than the curve order invalid. based on the order of the private key subgroup of bls12-381 and the size of the entropy utilised, more than 54% of keys generated by bip32 would be invalid. (secp256k1 keys derived by bip32 are invalid with probability less than 1 in 2-127.) establishing a multi-chain standard early on by establishing a standard before the first users begin to generate their keys, the hope is that a single standard is highly pervasive and therefore can be assumed to be the method by which the majority of keys are provided. this is valuable for two reasons, firstly in order for a post-quantum backup mechanism to be effective, there needs to be an enshrined mechanism whereby users can switch to a post-quantum signature scheme with pre-shared public keys (something this eip provides at 0 extra storage cost). secondly, this unifies the interand intra-chain ecosystem by having common tooling ideally allowing users to switch between key-management systems. a post-quantum backup this key derivation scheme has a lamport key pair which is generated as a intermediate step in the key generation process. this key pair can be used to provide a lamport signature which is a useful backup in the event of bls12-381 no longer being considered secure (in the event of quantum computing making a sudden advancement, for example). the idea is the lamport signature will act as a bridge to a new signature scheme which is deemed to be secure. specification version due to the evolving bls signatures cfrg draft (currently v4), the keygen function was updated, meaning that hkdf_mod_r no longer reflected what appeared in the bls standard. this eip was updated on the 17th of september 2020 to reflect this new method for deriving keys, if you are implementing this eip, please make sure your version is up to date. specification keys are defined in terms of a tree structure where a key is determined by the tree’s seed and a tree path. this is very useful as one can start with a single source of entropy and build out a practically unlimited number of keys. the specification can be broken into two sub-components: generating the master key, and constructing a child key from its parent. the master key is used as the root of the tree and then the tree is built in layers on top of this root. the tree structure the key tree is defined purely through the relationship between a child-node and its ancestors. starting with the root of the tree, the master key, a child node can be derived by knowing the parent’s private key and the index of the child. the tree is broken up into depths which are indicated by / and the master node is described as m. the first child of the master node is therefore described as m / 0 and m / 0’s siblings are m / i for all 0 <= i < 2**32. [m / 0] [m / 0 / 0] / \ / [m / 0 / 1] [m] [m / 1] \ ... [m / i] key derivation every key generated via the key derivation process derives a child key via a set of intermediate lamport keys. the idea behind the lamport keys is to provide a post-quantum backup in case bls12-381 is no longer deemed secure. at a high level, the key derivation process works by using the parent node’s privkey as an entropy source for the lamport private keys which are then hashed together into a compressed lamport public key, this public key is then hashed into bls12-381’s private key group. ikm_to_lamport_sk inputs ikm, a secret octet string salt, an octet string outputs lamport_sk, an array of 255 32-octet strings definitions hkdf-extract is as defined in rfc5869, instantiated with sha256 hkdf-expand is as defined in rfc5869, instantiated with sha256 k = 32 is the digest size (in octets) of the hash function (sha256) l = k * 255 is the hkdf output size (in octets) "" is the empty string bytes_split is a function takes in an octet string and splits it into k-byte chunks which are returned as an array procedure 0. prk = hkdf-extract(salt, ikm) 1. okm = hkdf-expand(prk, "" , l) 2. lamport_sk = bytes_split(okm, k) 3. return lamport_sk parent_sk_to_lamport_pk inputs parent_sk, the bls secret key of the parent node index, the index of the desired child node, an integer 0 <= index < 2^32 outputs lamport_pk, the compressed lamport pk, a 32 octet string definitions i2osp is as defined in rfc3447 (big endian decoding) flip_bits is a function that returns the bitwise negation of its input "" is the empty string a | b is the concatenation of a with b procedure 0. salt = i2osp(index, 4) 1. ikm = i2osp(parent_sk, 32) 2. lamport_0 = ikm_to_lamport_sk(ikm, salt) 3. not_ikm = flip_bits(ikm) 4. lamport_1 = ikm_to_lamport_sk(not_ikm, salt) 5. lamport_pk = "" 6. for i in 1, .., 255 lamport_pk = lamport_pk | sha256(lamport_0[i]) 7. for i in 1, .., 255 lamport_pk = lamport_pk | sha256(lamport_1[i]) 8. compressed_lamport_pk = sha256(lamport_pk) 9. return compressed_lamport_pk note: the indexing, i, in the above procedure iterates from 1 to 255 (inclusive). this is due to the limit to which hkdf can stretch the input bytes (255 times the length of the input bytes). the result of this is that the security of the lamport-backup signature is *only* 127.5 bit. hkdf_mod_r hkdf_mod_r() is used to hash 32 random bytes into the subgroup of the bls12-381 private keys. inputs ikm, a secret octet string >= 256 bits in length key_info, an optional octet string (default="", the empty string) outputs sk, the corresponding secret key, an integer 0 <= sk < r. definitions hkdf-extract is as defined in rfc5869, instantiated with hash h. hkdf-expand is as defined in rfc5869, instantiated with hash h. l is the integer given by ceil((3 * ceil(log2(r))) / 16).(l=48) "bls-sig-keygen-salt-" is an ascii string comprising 20 octets. os2ip is as defined in rfc3447 (big endian encoding) i2osp is as defined in rfc3447 (big endian decoding) r is the order of the bls 12-381 curve defined in the v4 draft ietf bls signature scheme standard r=52435875175126190479447740508185965837690552500527637822603658699938581184513 procedure 1. salt = "bls-sig-keygen-salt-" 2. sk = 0 3. while sk == 0: 4. salt = h(salt) 5. prk = hkdf-extract(salt, ikm || i2osp(0, 1)) 6. okm = hkdf-expand(prk, key_info || i2osp(l, 2), l) 7. sk = os2ip(okm) mod r 8. return sk derive_child_sk the child key derivation function takes in the parent’s private key and the index of the child and returns the child private key. inputs parent_sk, the secret key of the parent node, a big endian encoded integer index, the index of the desired child node, an integer 0 <= index < 2^32 outputs child_sk, the secret key of the child node, a big endian encoded integer procedure 0. compressed_lamport_pk = parent_sk_to_lamport_pk(parent_sk, index) 1. sk = hkdf_mod_r(compressed_lamport_pk) 2. return sk derive_master_sk the child key derivation function takes in the parent’s private key and the index of the child and returns the child private key. the seed should ideally be derived from a mnemonic, with the intention being that bip39 mnemonics, with the associated mnemonic_to_seed method be used. inputs seed, the source entropy for the entire tree, a octet string >= 256 bits in length outputs sk, the secret key of master node within the tree, a big endian encoded integer procedure 0. sk = hkdf_mod_r(seed) 1. return sk rationale lamport signatures lamport signatures are used as the backup mechanism because of their relative simplicity for a post-quantum signature scheme. lamport signatures are very easy both to explain and implement as the sole cryptographic dependency is a secure hash function. this is important as it minimises the complexity of implementing this standard as well as the compute time for deriving a key. lamport signatures have very large key sizes which make them impractical for many use cases, but this is not deemed to be an issue in this case as this scheme is only meant to be a once-off event to migrate to a new scheme. revealing the associated lamport public key for a corresponding bls key is done by verifying that the lamport public key is the pre-image of the corresponding bls private key (which in turn is verified against the bls public key). this means that using a key’s lamport signature reveals the bls private key rendering the bls key pair unsafe. this has the upside of not requiring additional storage space for backup keys alongside bls keys but does require that the lamport signatures be used once and that the bls key is no longer trusted after that point. the lamport signatures used within this scheme have 255 bits worth of security, not 256. this is done because hkdf-sha256, the mechanism used to stretch a key’s entropy, has a length-limit of 255 * hash_function_digest_size. the 1-bit reduction in security is deemed preferable over increasing the complexity of the entropy stretching mechanism. sha256 sha256 is used as the hash function throughout this standard as it is the hash function chosen by the ietf bls signature proposed standard. using a single hash function for everything decreases the number of cryptographic primitives required to implement the entire bls standardised key-stack while reducing the surface for flaws in the overall system. hkdf_mod_r() the function hkdf_mod_r() in this standard is the same as the keygen function described in the proposed standard and therefore the private key obtained from keygen is equal to that obtained from hkdf_mod_r for the same seed bytes. this means that common engineering can be done when implementing this function. additionally because of its inclusion in an ietf standard, it has had much scrutiny by many cryptographers and cryptanalysts, thereby lending credence to its safety as a key derivation mechanism. while hkdf_mod_r() has modulo bias, the magnitude of this bias is minuscule (the output size of hkdf is set to 48 bytes which is greater 2128 time larger than the curve order). this bias is deemed acceptable in light of the simplicity of the constant time scheme. only using hardened keys widely accepted standards that existed before this one (bip32 and bip44) utilise the notion of hardened and non-hardened keys whereas this specification only offers the former. non-hardened keys are primarily useful in a utxo system in which having one’s balance spilt amongst many accounts does not present much additionally complexity, but such keys are much less useful outside of this context. further complicating matters is the problem of deriving non-hardened keys using a post-quantum signature scheme as non-hardened keys are made possible by the very group arithmetic quantum computers gain an advantage over. backwards compatibility there are no major backwards compatibility issues brought upon by this eip as it is not designed for use within ethereum 1.0 as it currently stands. that said, this standard is not compatible with bip32/ bip44 style paths as paths specified by these systems make use of non-hardened keys, something that does not exist within this standard. test cases test case 0 seed = 0xc55257c360c07c72029aebc1b53c05ed0362ada38ead3e3e9efa3708e53495531f09a6987599d18264c1e1c92f2cf141630c7a3c4ab7c81b2f001698e7463b04 master_sk = 6083874454709270928345386274498605044986640685124978867557563392430687146096 child_index = 0 child_sk = 20397789859736650942317412262472558107875392172444076792671091975210932703118 this test case can be extended to test the entire mnemonic-to-child_sk stack, assuming bip39 is used as the mnemonic generation mechanism. using the following parameters, the above seed can be calculated: mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" passphrase = "trezor" this test case can be extended to test the entire mnemonic-to -child_sk stack, assuming bip39 is used as the mnemonic generation mechanism. using the following parameters, the above seed can be calculated: mnemonic = "abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon abandon about" passphrase = "trezor" test case 1 seed = 0x3141592653589793238462643383279502884197169399375105820974944592 master_sk = 29757020647961307431480504535336562678282505419141012933316116377660817309383 child_index = 3141592653 child_sk = 25457201688850691947727629385191704516744796114925897962676248250929345014287 test case 2 seed = 0x0099ff991111002299dd7744ee3355bbdd8844115566cc55663355668888cc00 master_sk = 27580842291869792442942448775674722299803720648445448686099262467207037398656 child_index = 4294967295 child_sk = 29358610794459428860402234341874281240803786294062035874021252734817515685787 test case 3 seed = 0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3 master_sk = 19022158461524446591288038168518313374041767046816487870552872741050760015818 child_index = 42 child_sk = 31372231650479070279774297061823572166496564838472787488249775572789064611981 test vector with intermediate values seed = 0xc55257c360c07c72029aebc1b53c05ed0362ada38ead3e3e9efa3708e53495531f09a6987599d18264c1e1c92f2cf141630c7a3c4ab7c81b2f001698e7463b04 master_sk = 6083874454709270928345386274498605044986640685124978867557563392430687146096 child_index = 0 lamport_0 = [0xe345d0ad7be270737de05cf036f688f385d5f99c7fddb054837658bdd2ebd519, 0x65050bd4db9c77c051f67dcc801bf1cdf33d81131e608505bb3e4523868eb76c, 0xc4f8e8d251fbdaed41bdd9c135b9ed5f83a614f49c38fffad67775a16575645a, 0x638ad0feace7567255120a4165a687829ca97e0205108b8b73a204fba6a66faa, 0xb29f95f64d0fcd0f45f265f15ff7209106ab5f5ce6a566eaa5b4a6f733139936, 0xbcfbdd744c391229f340f02c4f2d092b28fe9f1201d4253b9045838dd341a6bf, 0x8b9cf3531bfcf0e4acbfd4d7b4ed614fa2be7f81e9f4eaef53bedb509d0b186f, 0xb32fcc5c4e2a95fb674fa629f3e2e7d85335f6a4eafe7f0e6bb83246a7eced5f, 0xb4fe80f7ac23065e30c3398623b2761ac443902616e67ce55649aaa685d769ce, 0xb99354f04cfe5f393193c699b8a93e5e11e6be40ec16f04c739d9b58c1f55bf3, 0x93963f58802099ededb7843219efc66a097fab997c1501f8c7491991c780f169, 0x430f3b027dbe9bd6136c0f0524a0848dad67b253a11a0e4301b44074ebf82894, 0xd635c39b4a40ad8a54d9d49fc8111bd9d11fb65c3b30d8d3eaef7d7556aac805, 0x1f7253a6474cf0b2c05b02a7e91269137acddedcb548144821f9a90b10eccbab, 0x6e3bdb270b00e7b6eb8b044dbfae07b51ea7806e0d24218c59a807a7fd099c18, 0x895488ad2169d8eaae332ce5b0fe1e60ffab70e62e1cb15a2a1487544af0a6e8, 0x32d45a99d458c90e173a3087ea3661ab62d429b285089e92806a9663ba825342, 0xc15c52106c3177f5848a173076a20d46600ca65958a1e3c7d45a593aaa9670ed, 0xd8180c550fbe4cd6d5b676ff75e0728729d8e28a3b521d56152594ac6959d563, 0x58fe153fac8f4213aaf175e458435e06304548024bcb845844212c774bdffb2a, 0x10fff610a50f4bee5c978f512efa6ab4fafacb65929606951ba5b93eeb617b5a, 0x78ac9819799b52eba329f13dd52cf0f6148a80bf04f93341814c4b47bb4aa5ec, 0xa5c3339caa433fc11e74d1765bec577a13b054381a44b23c2482e750696876a9, 0x9f716640ab5cdc2a5eb016235cddca2dc41fa4ec5acd7e58af628dade99ec376, 0x2544364320e67577c4fed8c7c7c839deed93c24076d5343c5b8faca4cc6dc2d8, 0x62553e782541f822c589796be5d5c83bfc814819100b2be0710b246f5aa7149c, 0x229fb761c46c04b22ba5479f2696be0f936fded68d54dd74bcd736b8ba512afb, 0x0af23996a65b98a0ebaf19f3ec0b3ef20177d1bfd6eb958b3bd36e0bdbe04c8c, 0x6f0954f9deab52fd4c8d2daba69f73a80dea143dd49d9705c98db3d653adf98c, 0xfa9221dd8823919a95b35196c1faeb59713735827f3e84298c25c83ac700c480, 0x70c428e3ff9e5e3cda92d6bb85018fb89475c19f526461cca7cda64ebb2ff544, 0xdcaac3413e22314f0f402f8058a719b62966b3a7429f890d947be952f2e314ba, 0xb6b383cb5ec25afa701234824491916bfe6b09d28cf88185637e2367f0cf6edc, 0x7b0d91488fc916aba3e9cb61a5a5645b9def3b02e4884603542f679f602afb8d, 0xe9c20abca284acfde70c59584b9852b85c52fa7c263bb981389ff8d638429cd7, 0x838524f798daee6507652877feb9597f5c47e9bb5f9aa52a35fb6fff796813b9, 0xbe1ca18faf9bf322474fad1b3d9b4f1bc76ae9076e38e6dd2b16e2faf487742b, 0xbf02d70f1a8519343a16d24bade7f7222912fd57fe4f739f367dfd99d0337e8e, 0xc979eb67c107ff7ab257d1c0f4871adf327a4f2a69e01c42828ea27407caf058, 0xf769123d3a3f19eb7b5c3fd4f467a042944a7c5ff8834cebe427f47dbd71460c, 0xaefc8edc23257e1168a35999fe3832bcbc25053888cc89c38667482d6748095b, 0x8ff399f364d3a2428b1c92213e4fdc5341e7998007da46a5a2f671929b42aaab, 0xcf2a3d9e6963b24c5001fbba1e5ae7f45dd6cf520fd24861f745552db86bab48, 0xb380e272d7f3091e5c887fa2e7c690c67d59f4d95f8376d150e555da8c738559, 0xc006a749b091d91204dbb64f59059d284899de5986a7f84f8877afd5e0e4c253, 0x818d8bb9b7da2dafa2ef059f91975e7b6257f5e199d217320de0a576f020de5c, 0x7aabf4a1297d2e550a2ee20acb44c1033569e51b6ec09d95b22a8d131e30fd32, 0xdd01c80964a5d682418a616fb10810647c9425d150df643c8ddbbe1bfb2768b7, 0x1e2354e1d97d1b06eb6cfe9b3e611e8d75b5c57a444523e28a8f72a767eff115, 0x989c9a649dca0580256113e49ea0dd232bbfd312f68c272fe7c878acc5da7a2c, 0x14ee1efe512826fff9c028f8c7c86708b841f9dbf47ce4598298b01134ebdc1a, 0x6f861dba4503f85762d9741fa8b652ce441373f0ef2b7ebbd5a794e48cdab51b, 0xda110c9492ffdb87efe790214b7c9f707655a5ec08e5af19fb2ab2acc428e7dc, 0x5576aa898f6448d16e40473fcb24c46c609a3fc46a404559faa2d0d34d7d49ce, 0x9bd9a35675f2857792bc45893655bfdf905ffeaee942d93ad39fbcadd4ca9e11, 0xfa95e4c37db9303d5213890fd984034089cbc9c6d754741625da0aa59cc45ccf, 0xfef7d2079713f17b47239b76c8681bf7f800b1bfeac7a53265147579572ddf29, 0x39aa7c0fecf9a1ed037c685144745fda16da36f6d2004844cf0e2d608ef6ed0e, 0x5530654d502d6ba30f2b16f49cc5818279697308778fd8d40db8e84938144fb6, 0xb1beaa36397ba1521d7bf7df16536969d8a716e63510b1b82a715940180eb29f, 0x21abe342789f7c15a137afa373f686330c0db8c861572935a3cd8dcf9e4e1d45, 0x27b5a1acda55b4e0658887bd884d3203696fcae0e94f19e31bfe931342b1c257, 0x58401a02502d7708a812c0c72725f768f5a556480517258069f2d72543cda888, 0x4b38f291548f51bee7e4cf8cc5c8aa8f4ad3ec2461dba4ccbab70f1c1bfd7feb, 0x9b39a53fdafaaf1d23378e0aa8ae65d38480de69821de2910873eefc9f508568, 0x932200566a3563ee9141913d12fd1812cb008cb735724e8610890e101ec10112, 0x6a72f70b4ec5491f04780b17c4776a335fcc5bff5073d775150e08521dc74c91, 0x86d5c60e627a4b7d5d075b0ba33e779c45f3f46d22ed51f31360afd140851b67, 0x5ca2a736bb642abc4104faa781c9aff13d692a400d91dc961aec073889836946, 0xa14bca5a262ac46ceac21388a763561fc85fb9db343148d786826930f3e510cd, 0x87be03a87a9211504aa70ec149634ee1b97f7732c96377a3c04e98643dcba915, 0x8fe283bc19a377823377e9c326374ebb3f29527c12ea77bfb809c18eef8943b0, 0x8f519078b39a3969f7e4caeca9839d4e0eccc883b89e4a86d0e1731bfc5e33fc, 0x33d7c28c3d26fdfc015a8c2131920e1392ef0aea55505637b54ea63069c7858e, 0xe57de7c189fcc9170320c7acedb38798562a48dbc9943b2a8cd3441d58431128, 0x513dac46017050f82751a07b6c890f14ec43cadf687f7d202d2369e35b1836b4, 0xfd967d9f805bb7e78f7b7caa7692fdd3d6b5109c41ad239a08ad0a38eeb0ac4c, 0xf2013e4da9abcc0f03ca505ed94ec097556dbfd659088cd24ec223e02ac43329, 0xe0dcfac50633f7417f36231df2c81fa1203d358d5f57e896e1ab4b512196556b, 0xf022848130e73fe556490754ef0ecfcdaaf3b9ff16ae1eda7d38c95c4f159ded, 0x2147163a3339591ec7831d2412fb2d0588c38da3cd074fa2a4d3e5d21f9f1d2d, 0x11ee2404731962bf3238dca0d9759e06d1a5851308b4e6321090886ec5190b69, 0xf7679ecd07143f8ac166b66790fa09aed39352c09c0b4766bbe500b1ebace5a5, 0xc7a0e95f09076472e101813a95e6ea463c35bd5ee9cfda3e5d5dbccb35888ef0, 0xde625d3b547eb71bea5325a0191a592fa92a72e4b718a499fdba32e245ddf37e, 0x7e5bdccd95df216e8c59665073249072cb3c9d0aef6b341afc0ca90456942639, 0xc27f65fd9f797ede374e06b4ddb6e8aa59c7d6f36301f18b42c48b1889552fe3, 0x8175730a52ea571677b035f8e2482239dda1cfbff6bc5cde00603963511a81af, 0x09e440f2612dad1259012983dc6a1e24a73581feb1bd69d8a356eea16ba5fd0e, 0x59dcc81d594cbe735a495e38953e8133f8b3825fd84767af9e4ea06c49dbabfa, 0x6c8480b59a1a958c434b9680edea73b1207077fb9a8a19ea5f9fbbf6f47c4124, 0x81f5c89601893b7a5a231a7d37d6ab9aa4c57f174fcfc6b40002fa808714c3a1, 0x41ba4d6b4da141fcc1ee0f4b47a209cfd143d34e74fc7016e9956cedeb2db329, 0x5e0b5b404c60e9892040feacfb4a84a09c2bc4a8a5f54f3dad5dca4acdc899dc, 0xe922eebf1f5f15000d8967d16862ed274390cde808c75137d2fb9c2c0a80e391, 0xbf49d31a59a20484f0c08990b2345dfa954509aa1f8901566ab9da052b826745, 0xb84e07da828ae668c95d6aa31d4087504c372dbf4b5f8a8e4ded1bcf279fd52b, 0x89288bf52d8c4a9561421ad199204d794038c5d19ae9fee765ee2b5470e68e7e, 0xf6f618be99b85ec9a80b728454a417c647842215e2160c6fe547dd5a69bd9302, 0xdd9adc002f98c9a47c7b704fc0ce0a5c7861a5e2795b6014749cde8bcb8a034b, 0xd119a4b2c0db41fe01119115bcc35c4b7dbfdb42ad3cf2cc3f01c83732acb561, 0x9c66bc84d416b9193bad9349d8c665a9a06b835f82dc93ae0cccc218f808aad0, 0xd4b50eefcd2b5df075f14716cf6f2d26dfc8ae02e3993d711f4a287313038fde, 0xaf72bfb346c2f336b8bc100bff4ba35d006a3dad1c5952a0adb40789447f2704, 0xc43ca166f01dc955e7b4330227635feb1b0e0076a9c5633ca5c614a620244e5b, 0x5efca76970629521cfa053fbbbda8d3679cadc018e2e891043b0f52989cc2603, 0x35c57de1c788947f187051ce032ad1e899d9887d865266ec6fcfda49a8578b2b, 0x56d4be8a65b257216eab7e756ee547db5a882b4edcd12a84ed114fbd4f5be1f1, 0x257e858f8a4c07a41e6987aabaa425747af8b56546f2a3406f60d610bcc1f269, 0x40bd9ee36d52717ab22f1f6b0ee4fb38b594f58399e0bf680574570f1b4b8c90, 0xcb6ac01c21fc288c12973427c5df6eb8f6aefe64b92a6420c6388acdf36bc096, 0xa5716441312151a5f0deb52993a293884c6c8f445054ce1e395c96adeee66c6d, 0xe15696477f90113a10e04ba8225c28ad338c3b6bdd7bdeb95c0722921115ec85, 0x8faeaa52ca2f1d791cd6843330d16c75eaf6257e4ba236e3dda2bc1a644aee00, 0xc847fe595713bf136637ce8b43f9de238762953fed16798878344da909cc76ae, 0xb5740dc579594dd110078ce430b9696e6a308078022dde2d7cfe0ef7647b904e, 0x551a06d0771fcd3c53aea15aa8bf700047138ef1aa22265bee7fb965a84c9615, 0x9a65397a5907d604030508d41477de621ce4a0d79b772e81112d634455e7a4da, 0x6462d4cc2262d7faf8856812248dc608ae3d197bf2ef410f00c3ae43f2040995, 0x6782b1bd319568e30d54b324ab9ed8fdeac6515e36b609e428a60785e15fb301, 0x8bcdcf82c7eb2a07e14db20d80d9d2efea8d40320e121923784c92bf38250a8e, 0x46ed84fa17d226d5895e44685747ab82a97246e97d6237014611aaaba65ed268, 0x147e87981673326c5a2bdb06f5e90eaaa9583857129451eed6dde0c117fb061f, 0x4141d6fe070104c29879523ba6669552f3d457c0929bb878d2751f4ff059b895, 0xd866ce4ef226d74841f950fc28cdf2235db21e0e3f07a0c8f807704464db2210, 0xa804f9118bf92558f684f90c2bda832a4f51ef771ffb2765cde3ec6f48124f32, 0xc436d4a65910124e00cded9a637178914a8fbc090400f3f031c03eac4d0295a5, 0x643fdb9243656512316528de04dcc7344ca33783580ad0c3debf8c4a6e7c8bc4, 0x7f4a345b41706b281b2de998e91ff62d908eb29fc333ee336221757753c96e23, 0x6bdc086a5b11de950cabea33b72d98db886b291c4c2f02d3e997edc36785d249, 0xfb10b5b47d374078c0a52bff7174bf1cd14d872c7d20b4a009e2afd3017a9a17, 0x1e07e605312db5380afad8f3d7bd602998102fdd39565b618ac177b13a6527e6, 0xc3161b5a7b93aabf05652088b0e5b4803a18be693f590744c42c24c7aaaeef48, 0xa47e4f25112a7d276313f153d359bc11268b397933a5d5375d30151766bc689a, 0xb24260e2eff88716b5bf5cb75ea171ac030f5641a37ea89b3ac45acb30aae519, 0x2bcacbebc0a7f34406db2c088390b92ee34ae0f2922dedc51f9227b9afb46636, 0xc78c304f6dbe882c99c5e1354ce6077824cd42ed876db6706654551c7472a564, 0x6e2ee19d3ee440c78491f4e354a84fa593202e152d623ed899e700728744ac85, 0x2a3f438c5dc012aa0997b66f661b8c10f4a0cd7aa5b6e5922b1d73020561b27f, 0xd804f755d93173408988b95e9ea0e9feae10d404a090f73d9ff84df96f081cf7, 0xe06fda941b6936b8b33f00ffa02c8b05fd78fbec953da61da2043f5644b30a50, 0x45ee279b465d53148850a16cc7f6bd33e7627aef554a9418ed012ca8f9717f80, 0x9c79348c1bcd6aa2135452491d73564413a247ea8cc38fa7dcc6c43f8a2d61d5, 0x7c91e056f89f2a77d3e3642e595bcf4973c3bca68dd2b10f51ca0d8945e4255e, 0x669f976ebe38cbd22c5b1f785e14b76809d673d2cb1458983dbda41f5adf966b, 0x8bc71e99ffcc119fd8bd604af54c0663b0325a3203a214810fa2c588089ed5a7, 0x36b3f1ffeae5d9855e0965eef33f4c5133d99685802ac5ce5e1bb288d308f889, 0x0aad33df38b3f31598e04a42ec22f20bf2e2e9472d02371eb1f8a06434621180, 0x38c5632b81f90efbc51a729dcae03626a3063aa1f0a102fd0e4326e86a08a732, 0x6ea721753348ed799c98ffa330d801e6760c882f720125250889f107915e270a, 0xe700dd57ce8a653ce4269e6b1593a673d04d3de8b79b813354ac7c59d1b99adc, 0xe9294a24b560d62649ca898088dea35a644d0796906d41673e29e4ea8cd16021, 0xf20bb60d13a498a0ec01166bf630246c2f3b7481919b92019e2cfccb331f2791, 0xf639a667209acdd66301c8e8c2385e1189b755f00348d614dc92da14e6866b38, 0x49041904ee65c412ce2cd66d35570464882f60ac4e3dea40a97dd52ffc7b37a2, 0xdb36b16d3a1010ad172fc55976d45df7c03b05eab5432a77be41c2f739b361f8, 0x71400cdd2ea78ac1bf568c25a908e989f6d7e2a3690bc869c7c14e09c255d911, 0xf0d920b2d8a00b88f78e7894873a189c580747405beef5998912fc9266220d98, 0x1a2baefbbd41aa9f1cc5b10e0a7325c9798ba87de6a1302cf668a5de17bc926a, 0x449538a20e52fd61777c45d35ff6c2bcb9d9165c7eb02244d521317f07af6691, 0x97006755b9050b24c1855a58c4f4d52f01db4633baff4b4ef3d9c44013c5c665, 0xe441363a27b26d1fff3288222fa8ed540f8ca5d949ddcc5ff8afc634eec05336, 0xed587aa8752a42657fea1e68bc9616c40c68dcbbd5cb8d781e8574043e29ef28, 0x47d896133ba81299b8949fbadef1c00313d466827d6b13598685bcbb8776c1d2, 0x7786bc2cb2d619d07585e2ea4875f15efa22110e166af87b29d22af37b6c047d, 0x956b76194075fe3daf3ca508a6fad161deb05d0026a652929e37c2317239cbc6, 0xec9577cb7b85554b2383cc4239d043d14c08d005f0549af0eca6994e203cb4e7, 0x0722d0c68d38b23b83330b972254bbf9bfcf32104cc6416c2dad67224ac52887, 0x532b19d54fb6d77d96452d3e562b79bfd65175526cd793f26054c5f6f965df39, 0x4d62e065e57cbf60f975134a360da29cabdcea7fcfc664cf2014d23c733ab3b4, 0x09be0ea6b363fd746b303e482cb4e15ef25f8ae57b7143e64cbd5c4a1d069ebe, 0x69dcddc3e05147860d8d0e90d602ac454b609a82ae7bb960ee2ecd1627d77777, 0xa5e2ae69d902971000b1855b8066a4227a5be7234ac9513b3c769af79d997df4, 0xc287d4bc953dcff359d707caf2ccba8cc8312156eca8aafa261fb72412a0ea28, 0xb27584fd151fb30ed338f9cba28cf570f7ca39ebb03eb2e23140423af940bd96, 0x7e02928194441a5047af89a6b6555fea218f1df78bcdb5f274911b48d847f5f8, 0x9ba611add61ea6ba0d6d494c0c4edd03df9e6c03cafe10738cee8b7f45ce9476, 0x62647ec3109ac3db3f3d9ea78516859f0677cdde3ba2f27f00d7fda3a447dd01, 0xfa93ff6c25bfd9e17d520addf5ed2a60f1930278ff23866216584853f1287ac1, 0x3b391c2aa79c2a42888102cd99f1d2760b74f772c207a39a8515b6d18e66888a, 0xcc9ae3c14cbfb40bf01a09bcde913a3ed208e13e4b4edf54549eba2c0c948517, 0xc2b8bce78dd4e876da04c54a7053ca8b2bedc8c639cee82ee257c754c0bea2b2, 0xdb186f42871f438dba4d43755c59b81a6788cb3b544c0e1a3e463f6c2b6f7548, 0xb7f8ba137c7783137c0729de14855e20c2ac4416c33f5cac3b235d05acbab634, 0x282987e1f47e254e86d62bf681b0803df61340fdc9a8cf625ef2274f67fc6b5a, 0x04aa195b1aa736bf8875777e0aebf88147346d347613b5ab77bef8d1b502c08c, 0x3f732c559aee2b1e1117cf1dec4216a070259e4fa573a7dcadfa6aab74aec704, 0x72699d1351a59aa73fcede3856838953ee90c6aa5ef5f1f7e21c703fc0089083, 0x6d9ce1b8587e16a02218d5d5bed8e8d7da4ac40e1a8b46eeb412df35755c372c, 0x4f9c19b411c9a74b8616db1357dc0a7eaf213cb8cd2455a39eb7ae4515e7ff34, 0x9163dafa55b2b673fa7770b419a8ede4c7122e07919381225c240d1e90d90470, 0x268ff4507b42e623e423494d3bb0bc5c0917ee24996fb6d0ebedec9ce8cd9d5c, 0xff6e6169d233171ddc834e572024586eeb5b1bda9cb81e5ad1866dbc53dc75fe, 0xb379a9c8279205e8753b6a5c865fbbf70eb998f9005cd7cbde1511f81aed5256, 0x3a6b145e35a592e037c0992c9d259ef3212e17dca81045e446db2f3686380558, 0x60fb781d7b3137481c601871c1c3631992f4e01d415841b7f5414743dcb4cfd7, 0x90541b20b0c2ea49bca847e2db9b7bba5ce15b74e1d29194a12780e73686f3dd, 0xe2b0507c13ab66b4b769ad1a1a86834e385b315da2f716f7a7a8ff35a9e8f98c, 0xeefe54bc9fa94b921b20e7590979c28a97d8191d1074c7c68a656953e2836a72, 0x8676e7f59d6f2ebb0edda746fc1589ef55e07feab00d7008a0f2f6f129b7bb3a, 0x78a3d93181b40152bd5a8d84d0df7f2adde5db7529325c13bc24a5b388aed3c4, 0xcc0e2d0cba7aaa19c874dbf0393d847086a980628f7459e9204fda39fad375c0, 0x6e46a52cd7745f84048998df1a966736d2ac09a95a1c553016fef6b9ec156575, 0x204ac2831d2376d4f9c1f5c106760851da968dbfc488dc8a715d1c764c238263, 0xbdb8cc7b7e5042a947fca6c000c10b9b584e965c3590f92f6af3fe4fb23e1358, 0x4a55e4b8a138e8508e7b11726f617dcf4155714d4600e7d593fd965657fcbd89, 0xdfe064bb37f28d97b16d58b575844964205e7606dce914a661f2afa89157c45b, 0x560e374fc0edda5848eef7ff06471545fcbdd8aefb2ecddd35dfbb4cb03b7ddf, 0x10a66c82e146da5ec6f48b614080741bc51322a60d208a87090ad7c7bf6b71c6, 0x62534c7dc682cbf356e6081fc397c0a17221b88508eaeff798d5977f85630d4f, 0x0138bba8de2331861275356f6302b0e7424bbc74d88d8c534479e17a3494a15b, 0x580c7768bf151175714b4a6f2685dc5bcfeb088706ee7ed5236604888b84d3e4, 0xd290adb1a5dfc69da431c1c0c13da3be788363238d7b46bc20185edb45ab9139, 0x1689879db6c78eb4d3038ed81be1bc106f8cfa70a7c6245bd4be642bfa02ebd7, 0x6064c384002c8b1594e738954ed4088a0430316738def62822d08b2285514918, 0x01fd23493f4f1cc3c5ff4e96a9ee386b2a144b50a428a6b5db654072bddadfe7, 0xd5d05bb7f23ab0fa2b82fb1fb14ac29c2477d81a85423d0a45a4b7d5bfd81619, 0xd72b9a73ae7b24db03b84e01106cea734d4b9d9850b0b7e9d65d6001d859c772, 0x156317cb64578db93fee2123749aff58c81eae82b189b0d6f466f91de02b59df, 0x5fba299f3b2c099edbac18d785be61852225890fc004bf6be0787d62926a79b3, 0x004154f28f685bdbf0f0d6571e7a962a4c29b6c3ebedaaaf66097dfe8ae5f756, 0x4b45816f9834c3b289affce7a3dc80056c2b7ffd3e3c250d6dff7f923e7af695, 0x6ca53bc37816fff82346946d83bef87860626bbee7fd6ee9a4aeb904d893a11f, 0xf48b2f43184358d66d5b5f7dd2b14a741c7441cc7a33ba3ebcc94a7b0192d496, 0x3cb98f4baa429250311f93b46e745174f65f901fab4eb8075d380908aaaef650, 0x343dfc26b4473b3a20e706a8e87e5202a4e6b96b53ed448afb9180c3f766e5f8, 0x1ace0e8a735073bcbaea001af75b681298ef3b84f1dbab46ea52cee95ab0e7f9, 0xd239b110dd71460cdbc41ddc99494a7531186c09da2a697d6351c116e667733b, 0x22d6955236bd275969b8a6a30c23932670a6067f68e236d2869b6a8b4b493b83, 0x53c1c01f8d061ac89187e5815ef924751412e6a6aa4dc8e3abafb1807506b4e0, 0x2f56dd20c44d7370b713e7d7a1bfb1a800cac33f8a6157f278e17a943806a1f7, 0xc99773d8a5b3e60115896a65ac1d6c15863317d403ef58b90cb89846f4715a7f, 0x9f4b6b77c254094621cd336da06fbc6cbb7b8b1d2afa8e537ceca1053c561ef5, 0x87944d0b210ae0a6c201cba04e293f606c42ebaed8b4a5d1c33f56863ae7e1b5, 0xa7d116d962d03ca31a455f9cda90f33638fb36d3e3506605aa19ead554487a37, 0x4042e32e224889efd724899c9edb57a703e63a404129ec99858048fbc12f2ce0, 0x36759f7a0faeea1cd4cb91e404e4bf09908de6e53739603d5f0db52b664158a3, 0xa4d50d005fb7b9fea8f86f1c92439cc9b8446efef7333ca03a8f6a35b2d49c38, 0x80cb7c3e20f619006542edbe71837cdadc12161890a69eea8f41be2ee14c08a3, 0xbb3c44e1df45f2bb93fb80e7f82cee886c153ab484c0095b1c18df03523629b4, 0x04cb749e70fac3ac60dea779fceb0730b2ec5b915b0f8cf28a6246cf6da5db29, 0x4f5189b8f650687e65a962ef3372645432b0c1727563777433ade7fa26f8a728, 0x322eddddf0898513697599b68987be5f88c0258841affec48eb17cf3f61248e8, 0x6416be41cda27711d9ec22b3c0ed4364ff6975a24a774179c52ef7e6de9718d6, 0x0622d31b8c4ac7f2e30448bdadfebd5baddc865e0759057a6bf7d2a2c8b527e2, 0x40f096513588cc19c08a69e4a48ab6a43739df4450b86d3ec2fb3c6a743b5485, 0x09fcf7d49290785c9ea2d54c3d63f84f6ea0a2e9acfcdbb0cc3a281ce438250e, 0x2000a519bf3da827f580982d449b5c70fcc0d4fa232addabe47bb8b1c471e62e, 0xf4f80008518e200c40b043f34fb87a6f61b82f8c737bd784292911af3740245e, 0x939eaab59f3d2ad49e50a0220080882319db7633274a978ced03489870945a65, 0xadcad043d8c753fb10689280b7670f313253f5d719039e250a673d94441ee17c, 0x58b7b75f090166b8954c61057074707d7e38d55ce39d9b2251bbc3d72be458f8, 0xf61031890c94c5f87229ec608f2a9aa0a3f455ba8094b78395ae312cbfa04087, 0x356a55def50139f94945e4ea432e7a9defa5db7975462ebb6ca99601c614ea1d, 0x65963bb743d5db080005c4db59e29c4a4e86f92ab1dd7a59f69ea7eaf8e9aa79] lamport_1 = [0x9c0bfb14de8d2779f88fc8d5b016f8668be9e231e745640096d35dd5f53b0ae2, 0x756586b0f3227ab0df6f4b7362786916bd89f353d0739fffa534368d8d793816, 0x710108dddc39e579dcf0819f9ad107b3c56d1713530dd94325db1d853a675a37, 0x8862b5f428ce5da50c89afb50aa779bb2c4dfe60e6f6a070b3a0208a4a970fe5, 0x54a9cd342fa3a4bf685c01d1ce84f3068b0d5b6a58ee22dda8fbac4908bb9560, 0x0fa3800efeaddd28247e114a1cf0f86b9014ccae9c3ee5f8488168b1103c1b44, 0xbb393428b7ebfe2eda218730f93925d2e80c020d41a29f4746dcbb9138f7233a, 0x7b42710942ef38ef2ff8fe44848335f26189c88c22a49fda84a51512ac68cd5d, 0x90e99786a3e8b04db95ccd44d01e75558d75f3ddd12a1e9a2c2ce76258bf4813, 0x3f6f71e40251728aa760763d25deeae54dc3a9b53807c737deee219120a2230a, 0xe56081a7933c6eaf4ef2c5a04e21ab8a3897785dd83a34719d1b62d82cfd00c2, 0x76cc54fa15f53e326575a9a2ac0b8ed2869403b6b6488ce4f3934f17db0f6bee, 0x1cd9cd1d882ea3830e95162b5de4beb5ddff34fdbf7aec64e83b82a6d11b417c, 0xb8ca8ae36d717c448aa27405037e44d9ee28bb8c6cc538a5d22e4535c8befd84, 0x5c4492108c25f873a23d5fd7957b3229edc22858e8894febe7428c0831601982, 0x907bcd75e7465e9791dc34e684742a2c0dc7007736313a95070a7e6b961c9c46, 0xe7134b1511559e6b2440672073fa303ec3915398e75086149eb004f55e893214, 0x2ddc2415e4753bfc383d48733e8b2a3f082883595edc5515514ebb872119af09, 0xf2ad0f76b08ffa1eee62228ba76f4982fab4fbede5d4752c282c3541900bcd5b, 0x0a84a6b15abd1cbc2da7092bf7bac418b8002b7000236dfba7c8335f27e0f1d4, 0x97404e02b9ff5478c928e1e211850c08cc553ebac5d4754d13efd92588b1f20d, 0xfa6ca3bcff1f45b557cdec34cb465ab06ade397e9d9470a658901e1f0f124659, 0x5bd972d55f5472e5b08988ee4bccc7240a8019a5ba338405528cc8a38b29bc21, 0x52952e4f96c803bb76749800891e3bfe55f7372facd5b5a587a39ac10b161bcc, 0xf96731ae09abcad016fd81dc4218bbb5b2cb5fe2e177a715113f381814007314, 0xe7d79e07cf9f2b52623491519a21a0a3d045401a5e7e10dd8873a85076616326, 0xe4892f3777a4614ee6770b22098eaa0a3f32c5c44b54ecedacd69789d676dffe, 0x20c932574779e2cc57780933d1dc6ce51a5ef920ce5bf681f7647ac751106367, 0x057252c573908e227cc07797117701623a4835f4b047dcaa9678105299e48e70, 0x20bad780930fa2a036fe1dea4ccbf46ac5b3c489818cdb0f97ae49d6e2f11fbf, 0xc0d7dd26ffecdb098585a1694e45a54029bb1e31c7c5209289058efebb4cc91b, 0x9a8744beb1935c0abe4b11812fc02748ef7c8cb650db3024dde3c5463e9d8714, 0x8ce6eea4585bbeb657b326daa4f01f6aef34954338b3ca42074aedd1110ba495, 0x1c85b43f5488b370721290d2faea19d9918d094c99963d6863acdfeeca564363, 0xe88a244347e448349e32d0525b40b18533ea227a9d3e9b78a9ff14ce0a586061, 0x352ca61efc5b8ff9ee78e738e749142dd1606154801a1449bbb278fa6bcc3dbe, 0xa066926f9209220b24ea586fb20eb8199a05a247c82d7af60b380f6237429be7, 0x3052337ccc990bfbae26d2f9fe5d7a4eb8edfb83a03203dca406fba9f4509b6e, 0x343ce573a93c272688a068d758df53c0161aa7f9b55dec8beced363a38b33069, 0x0f16b5593f133b58d706fe1793113a10750e8111eadee65301df7a1e84f782d3, 0x808ae8539357e85b648020f1e9d255bc4114bee731a6220d7c5bcb5b85224e03, 0x3b2bd97e31909251752ac57eda6015bb05b85f2838d475095cfd146677430625, 0xe4f857c93b2d8b250050c7381a6c7c660bd29066195806c8ef11a2e6a6640236, 0x23d91589b5070f443ddcefa0838c596518d54928119251ecf3ec0946a8128f52, 0xb72736dfad52503c7f5f0c59827fb6ef4ef75909ff9526268abc0f296ee37296, 0x80a8c66436d86b8afe87dde7e53a53ef87e057a5d4995963e76d159286de61b6, 0xbec92c09ee5e0c84d5a8ba6ca329683ff550ace34631ea607a3a21f99cd36d67, 0x83c97c9807b9ba6d9d914ae49dabdb4c55e12e35013f9b179e6bc92d5d62222b, 0x8d9c79f6af3920672dc4cf97a297c186e75083d099aeb5c1051207bad0c98964, 0x2aaa5944a2bd852b0b1be3166e88f357db097b001c1a71ba92040b473b30a607, 0x46693d27ec4b764fbb516017c037c441f4558aebfe972cdcd03da67c98404e19, 0x903b25d9e12208438f203c9ae2615b87f41633d5ffda9cf3f124c1c3922ba08f, 0x3ec23dc8bc1b49f5c7160d78008f3f235252086a0a0fa3a7a5a3a53ad29ec410, 0xa1fe74ceaf3cccd992001583a0783d7d7b7a245ea374f369133585b576b9c6d8, 0xb2d6b0fe4932a2e06b99531232398f39a45b0f64c3d4ebeaaebc8f8e50a80607, 0xe19893353f9214eebf08e5d83c6d44c24bffe0eceee4dc2e840d42eab0642536, 0x5b798e4bc099fa2e2b4b5b90335c51befc9bbab31b4dd02451b0abd09c06ee79, 0xbab2cdec1553a408cac8e61d9e6e19fb8ccfb48efe6d02bd49467a26eeeca920, 0x1c1a544c28c38e5c423fe701506693511b3bc5f2af9771b9b2243cd8d41bebfc, 0x704d6549d99be8cdefeec9a58957f75a2be4af7bc3dc4655fa606e7f3e03b030, 0x051330f43fe39b08ed7d82d68c49b36a8bfa31357b546bfb32068712df89d190, 0xe69174c7b03896461cab2dfaab33d549e3aac15e6b0f6f6f466fb31dae709b9b, 0xe5f668603e0ddbbcde585ac41c54c3c4a681fffb7a5deb205344de294758e6ac, 0xca70d5e4c3a81c1f21f246a3f52c41eaef9a683f38eb7c512eac8b385f46cbcd, 0x3173a6b882b21cd147f0fc60ef8f24bbc42104caed4f9b154f2d2eafc3a56907, 0xc71469c192bf5cc36242f6365727f57a19f924618b8a908ef885d8f459833cc3, 0x59c596fc388afd8508bd0f5a1e767f3dda9ed30f6646d15bc59f0b07c4de646f, 0xb200faf29368581f551bd351d357b6fa8cbf90bdc73b37335e51cad36b4cba83, 0x275cede69b67a9ee0fff1a762345261cb20fa8191470159cc65c7885cfb8313c, 0x0ce4ef84916efbe1ba9a0589bed098793b1ea529758ea089fd79151cc9dc7494, 0x0f08483bb720e766d60a3cbd902ce7c9d835d3f7fdf6dbe1f37bcf2f0d4764a2, 0xb30a73e5db2464e6da47d10667c82926fa91fceb337d89a52db5169008bc6726, 0x6b9c50fed1cc404bf2dd6fffbfd18e30a4caa1500bfeb080aa93f78d10331aaf, 0xf17c84286df03ce175966f560600dd562e0f59f18f1d1276b4d8aca545d57856, 0x11455f2ef96a6b2be69854431ee219806008eb80ea38c81e45b2e58b3f975a20, 0x9a61e03e2157a5c403dfcde690f7b7d704dd56ea1716cf14cf7111075a8d6491, 0x30312c910ce6b39e00dbaa669f0fb7823a51f20e83eaeb5afa63fb57668cc2f4, 0x17c18d261d94fba82886853a4f262b9c8b915ed3263b0052ece5826fd7e7d906, 0x2d8f6ea0f5b9d0e4bc1478161f5ed2ad3d8495938b414dcaec9548adbe572671, 0x19954625f13d9bab758074bf6dee47484260d29ee118347c1701aaa74abd9848, 0x842ef2ad456e6f53d75e91e8744b96398df80350cf7af90b145fea51fbbcf067, 0x34a8b0a76ac20308aa5175710fb3e75c275b1ff25dba17c04e3a3e3c48ca222c, 0x58efcbe75f32577afe5e9ff827624368b1559c32fcca0cf4fd704af8ce019c63, 0x411b4d242ef8f14d92bd8b0b01cb4fa3ca6f29c6f9073cfdd3ce614fa717463b, 0xf76dbda66ede5e789314a88cff87ecb4bd9ca418c75417d4d920e0d21a523257, 0xd801821a0f87b4520c1b003fe4936b6852c410ee00b46fb0f81621c9ac6bf6b4, 0x97ad11d6a29c8cf3c548c094c92f077014de3629d1e9053a25dbfaf7eb55f72d, 0xa87012090cd19886d49521d564ab2ad0f18fd489599050c42213bb960c9ee8ff, 0x8868d8a26e758d50913f2bf228da0444a206e52853bb42dd8f90f09abe9c859a, 0xc257fb0cc9970e02830571bf062a14540556abad2a1a158f17a18f14b8bcbe95, 0xfe611ce27238541b14dc174b652dd06719dfbcda846a027f9d1a9e8e9df2c065, 0xc9b25ea410f420cc2d4fc6057801d180c6cab959bce56bf6120f555966e6de6d, 0x95437f0524ec3c04d4132c83be7f1a603e6f4743a85ede25aa97a1a4e3f3f8fc, 0x82a12910104065f35e983699c4b9187aed0ab0ec6146f91728901efecc7e2e20, 0x6622dd11e09252004fb5aaa39e283333c0686065f228c48a5b55ee2060dbd139, 0x89a2879f25733dab254e4fa6fddb4f04b8ddf018bf9ad5c162aea5c858e6faaa, 0x8a71b62075a6011fd9b65d956108fa79cc9ebb8f194d64d3105a164e01cf43a6, 0x103f4fe9ce211b6452181371f0dc4a30a557064b684645a4495136f4ebd0936a, 0x97914adc5d7ce80147c2f44a6b29d0b495d38dedd8cc299064abcc62ed1ddabc, 0x825c481da6c836a8696d7fda4b0563d204a9e7d9e4c47b46ded26db3e2d7d734, 0xf8c0637ba4c0a383229f1d730db733bc11d6a4e33214216c23f69ec965dcaaad, 0xaed3bdaf0cb12d37764d243ee0e8acdefc399be2cabbf1e51dc43454efd79cbd, 0xe8427f56cc5cec8554e2f5f586b57adccbea97d5fc3ef7b8bbe97c2097cf848c, 0xba4ad0abd5c14d526357fd0b6f8676ef6126aeb4a6d80cabe1f1281b9d28246c, 0x4cff20b72e2ab5af3fafbf9222146949527c25f485ec032f22d94567ff91b22f, 0x0d32925d89dd8fed989912afcbe830a4b5f8f7ae1a3e08ff1d3a575a77071d99, 0xe51a1cbeae0be5d2fdbc7941aea904d3eade273f7477f60d5dd6a12807246030, 0xfb8615046c969ef0fa5e6dc9628c8a9880e86a5dc2f6fc87aff216ea83fcf161, 0x64dd705e105c88861470d112c64ca3d038f67660a02d3050ea36c34a9ebf47f9, 0xb6ad148095c97528180f60fa7e8609bf5ce92bd562682092d79228c2e6f0750c, 0x5bae0cd81f3bd0384ca3143a72068e6010b946462a73299e746ca639c026781c, 0xc39a0fc7764fcfc0402b12fb0bbe78fe3633cbfb33c7f849279585a878a26d7c, 0x2b752fda1c0c53d685cc91144f78d371db6b766725872b62cc99e1234cca8c1a, 0x40ee6b9635d87c95a528757729212a261843ecb06d975de91352d43ca3c7f196, 0x75e2005d3726cf8a4bb97ea5287849a361e3f8fdfadc3c1372feed1208c89f6b, 0x0976f8ab556153964b58158678a5297da4d6ad92e284da46052a791ee667aee4, 0xdbeef07841e41e0672771fb550a5b9233ae8e9256e23fa0d34d5ae5efe067ec8, 0xa890f412ab6061c0c5ee661e80d4edc5c36b22fb79ac172ddd5ff26a7dbe9751, 0xb666ae07f9276f6d0a33f9efeb3c5cfcba314fbc06e947563db92a40d7a341e8, 0x83a082cf97ee78fbd7f31a01ae72e40c2e980a6dab756161544c27da86043528, 0xfa726a919c6f8840c456dc77b0fec5adbed729e0efbb9317b75f77ed479c0f44, 0xa8606800c54faeab2cbc9d85ff556c49dd7e1a0476027e0f7ce2c1dc2ba7ccbf, 0x2796277836ab4c17a584c9f6c7778d10912cb19e541fb75453796841e1f6cd1c, 0xf648b8b3c7be06f1f8d9cda13fd6d60f913e5048a8e0b283b110ca427eeb715f, 0xa21d00b8fdcd77295d4064e00fbc30bed579d8255e9cf3a9016911d832390717, 0xe741afcd98cbb3bb140737ed77bb968ac60d5c00022d722f9f04f56e97235dc9, 0xbeecc9638fac39708ec16910e5b02c91f83f6321f6eb658cf8a96353cfb49806, 0x912eee6cabeb0fed8d6e6ca0ba61977fd8e09ea0780ff8fbec995e2a85e08b52, 0xc665bc0bb121a1229bc56ecc07a7e234fd24c523ea14700aa09e569b5f53ad33, 0x39501621c2bdff2f62ab8d8e3fe47fe1701a98c665697c5b750ee1892f11846e, 0x03d32e16c3a6c913daefb139f131e1e95a742b7be8e20ee39b785b4772a50e44, 0x4f504eb46a82d440f1c952a06f143994bc66eb9e3ed865080cd9dfc6d652b69c, 0xad753dc8710a46a70e19189d8fc7f4c773e4d9ccc7a70c354b574fe377328741, 0xf7f5464a2d723b81502adb9133a0a4f0589b4134ca595a82e660987c6b011610, 0x216b60b1c3e3bb4213ab5d43e04619d13e1ecedbdd65a1752bda326223e3ca3e, 0x763664aa96d27b6e2ac7974e3ca9c9d2a702911bc5d550d246631965cf2bd4a2, 0x292b5c8c8431b040c04d631f313d4e6b67b5fd3d4b8ac9f2edb09d13ec61f088, 0x80db43c2b9e56eb540592f15f5900222faf3f75ce62e78189b5aa98c54568a5e, 0x1b5fdf8969bcd4d65e86a2cefb3a673e18d587843f4f50db4e3ee77a0ba2ef1c, 0x11e237953fff3e95e6572da50a92768467ffdfd0640d3384aa1c486357e7c24a, 0x1fabd4faa8dba44808cc87d0bc389654a98496745578f3d17d134adc7f7b10f3, 0x5eca4aa96f20a56197772ae6b600762154ca9d2702cab12664ea47cbff1a440c, 0x0b4234f5bb02abcf3b5ce6c44ea85f55ec7db98fa5a7b90abef6dd0df034743c, 0x316761e295bf350313c4c92efea591b522f1df4211ce94b22e601f30aefa51ef, 0xe93a55ddb4d7dfe02598e8f909ff34b3de40a1c0ac8c7fba48cb604ea60631fb, 0xe6e6c877b996857637f8a71d0cd9a6d47fdeb03752c8965766f010073332b087, 0xa4f95c8874e611eddd2c4502e4e1196f0f1be90bfc37db35f8588e7d81d34aeb, 0x9351710a5633714bb8b2d226e15ba4caa6f50f56c5508e5fa1239d5cc6a7e1aa, 0x8d0aef52ec7266f37adb572913a6213b8448caaf0384008373dec525ae6cdff1, 0x718e24c3970c85bcb14d2763201812c43abac0a7f16fc5787a7a7b2f37288586, 0x3600ce44cebc3ee46b39734532128eaf715c0f3596b554f8478b961b0d6e389a, 0x50dd1db7b0a5f6bd2d16252f43254d0f5d009e59f61ebc817c4bbf388519a46b, 0x67861ed00f5fef446e1f4e671950ac2ddae1f3b564f1a6fe945e91678724ef03, 0x0e332c26e169648bc20b4f430fbf8c26c6edf1a235f978d09d4a74c7b8754aad, 0x6c9901015adf56e564dfb51d41a82bde43fb67273b6911c9ef7fa817555c9557, 0x53c83391e5e0a024f68d5ade39b7a769f10664e12e4942c236398dd5dbce47a1, 0x78619564f0b2399a9fcb229d938bf1e298d62b03b7a37fe6486034185d7f7d27, 0x4625f15381a8723452ec80f3dd0293c213ae35de737c508f42427e1735398c3a, 0x69542425ddb39d3d3981e76b41173eb1a09500f11164658a3536bf3e292f8b6a, 0x82ac4f5bb40aece7d6706f1bdf4dfba5c835c09afba6446ef408d8ec6c09300f, 0x740f9180671091b4c5b3ca59b9515bd0fc751f48e488a9f7f4b6848602490e21, 0x9a04b08b4115986d8848e80960ad67490923154617cb82b3d88656ec1176c24c, 0xf9ffe528eccffad519819d9eef70cef317af33899bcaee16f1e720caf9a98744, 0x46da5e1a14b582b237f75556a0fd108c4ea0d55c0edd8f5d06c59a42e57410df, 0x098f3429c8ccda60c3b5b9755e5632dd6a3f5297ee819bec8de2d8d37893968a, 0x1a5b91af6025c11911ac072a98b8a44ed81f1f3c76ae752bd28004915db6f554, 0x8bed50c7cae549ed4f8e05e02aa09b2a614c0af8eec719e4c6f7aee975ec3ec7, 0xd86130f624b5dcc116f2dfbb5219b1afde4b7780780decd0b42694e15c1f8d8b, 0x4167aa9bc0075f624d25d40eb29139dd2c452ebf17739fab859e14ac6765337a, 0xa258ce5db20e91fb2ea30d607ac2f588bdc1924b21bbe39dc881e19889a7f5c6, 0xe5ef8b5ab3cc8894452d16dc875b69a55fd925808ac7cafef1cd19485d0bb50a, 0x120df2b3975d85b6dfca56bb98a82025ade5ac1d33e4319d2e0105b8de9ebf58, 0xc964291dd2e0807a468396ebba3d59cfe385d949f6d6215976fc9a0a11de209a, 0xf23f14cb709074b79abe166f159bc52b50de687464df6a5ebf112aa953c95ad5, 0x622c092c9bd7e30f880043762e26d8e9c73ab7c0d0806f3c5e472a4152b35a93, 0x8a5f090662731e7422bf651187fb89812419ab6808f2c62da213d6944fccfe9f, 0xfbea3c0d92e061fd2399606f42647d65cc54191fa46d57b325103a75f5c22ba6, 0x2babfbcc08d69b52c3747ddc8dcad4ea5511edabf24496f3ff96a1194d6f680e, 0x4d3d019c28c779496b616d85aee201a3d79d9eecf35f728d00bcb12245ace703, 0xe76fcee1f08325110436f8d4a95476251326b4827399f9b2ef7e12b7fb9c4ba1, 0x4884d9c0bb4a9454ea37926591fc3eed2a28356e0506106a18f093035638da93, 0x74c3f303d93d4cc4f0c1eb1b4378d34139220eb836628b82b649d1deb519b1d3, 0xacb806670b278d3f0c84ba9c7a68c7df3b89e3451731a55d7351468c7c864c1c, 0x8660fb8cd97e585ea7a41bccb22dd46e07eee8bbf34d90f0f0ca854b93b1ebee, 0x2fc9c89cdca71a1c0224d469d0c364c96bbd99c1067a7ebe8ef412c645357a76, 0x8ec6d5ab6ad7135d66091b8bf269be44c20af1d828694cd8650b5479156fd700, 0x50ab4776e8cabe3d864fb7a1637de83f8fbb45d6e49645555ffe9526b27ebd66, 0xbf39f5e17082983da4f409f91c7d9059acd02ccbefa69694aca475bb8d40b224, 0x3135b3b981c850cc3fe9754ec6af117459d355ad6b0915beb61e84ea735c31bf, 0xa7971dab52ce4bf45813223b0695f8e87f64b614c9c5499faac6f842e5c41be9, 0x9e480f5617323ab104b4087ac4ef849a5da03427712fb302ac085507c77d8f37, 0x57a6d474654d5e8d408159be39ad0e7026e6a4c6a6543e23a63d30610dc8dfc1, 0x09eb3e01a5915a4e26d90b4c58bf0cf1e560fdc8ba53faed9d946ad3e9bc78fa, 0x29c6d25da80a772310226b1b89d845c7916e4a4bc94d75aa330ec3eaa14b1e28, 0x1a1ccfee11edeb989ca02e3cb89f062612a22a69ec816a625835d79370173987, 0x1cb63dc541cf7f71c1c4e8cabd2619c3503c0ea1362dec75eccdf1e9efdbfcfc, 0xac9dff32a69e75b396a2c250e206b36c34c63b955c9e5732e65eaf7ccca03c62, 0x3e1b4f0c3ebd3d38cec389720147746774fc01ff6bdd065f0baf2906b16766a8, 0x5cc8bed25574463026205e90aad828521f8e3d440970d7e810d1b46849681db5, 0x255185d264509bd3a768bb0d50b568e66eb1fec96d573e33aaacc716d7c8fb93, 0xe81b86ba631973918a859ff5995d7840b12511184c2865401f2693a71b9fa07e, 0x61e67e42616598da8d36e865b282127c761380d3a56d26b8d35fbbc7641433c5, 0x60c62ffef83fe603a34ca20b549522394e650dad5510ae68b6e074f0cd209a56, 0x78577f2caf4a54f6065593535d76216f5f4075af7e7a98b79571d33b1822920c, 0xfd4cb354f2869c8650200de0fe06f3d39e4dbebf19b0c1c2677da916ea84f44d, 0x453769cef6ff9ba2d5c917982a1ad3e2f7e947d9ea228857556af0005665e0b0, 0xe567f93f8f88bf1a6b33214f17f5d60c5dbbb531b4ab21b8c0b799b6416891e0, 0x7e65a39a17f902a30ceb2469fe21cba8d4e0da9740fcefd5c647c81ff1ae95fa, 0x03e4a7eea0cd6fc02b987138ef88e8795b5f839636ca07f6665bbae9e5878931, 0xc3558e2b437cf0347cabc63c95fa2710d3f43c65d380feb998511903f9f4dcf0, 0xe3a615f80882fb5dfbd08c1d7a8b0a4d3b651d5e8221f99b879cb01d97037a9c, 0xb56db4a5fea85cbffaee41f05304689ea321c40d4c108b1146fa69118431d9b2, 0xab28e1f077f18117945910c235bc9c6f9b6d2b45e9ef03009053006c637e3e26, 0xefcabc1d5659fd6e48430dbfcc9fb4e08e8a9b895f7bf9b3d6c7661bfc44ada2, 0xc7547496f212873e7c3631dafaca62a6e95ac39272acf25a7394bac6ea1ae357, 0xc482013cb01bd69e0ea9f447b611b06623352e321469f4adc739e3ee189298eb, 0x5942f42e91e391bb44bb2c4d40da1906164dbb6d1c184f00fa62899baa0dba2c, 0xb4bcb46c80ad4cd603aff2c1baf8f2c896a628a46cc5786f0e58dae846694677, 0xd0a7305b995fa8c317c330118fee4bfef9f65f70b54558c0988945b08e90ff08, 0x687f801b7f32fdfa7d50274cc7b126efedbdae8de154d36395d33967216f3086, 0xeb19ec10ac6c15ffa619fa46792971ee22a9328fa53bd69a10ed6e9617dd1bbf, 0xa2bb3f0367f62abdb3a9fa6da34b20697cf214a4ff14fd42826da140ee025213, 0x070a76511f32c882374400af59b22d88974a06fbc10d786dd07ca7527ebd8b90, 0x8f195689537b446e946b376ec1e9eb5af5b4542ab47be550a5700fa5d81440d5, 0x10cc09778699fc8ac109e7e6773f83391eeba2a6db5226fbe953dd8d99126ca5, 0x8cc839cb7dc84fd3b8c0c7ca637e86a2f72a8715cc16c7afb597d12da717530b, 0xa32504e6cc6fd0ee441440f213f082fcf76f72d36b5e2a0f3b6bdd50cdd825a2, 0x8f45151db8878e51eec12c450b69fa92176af21a4543bb78c0d4c27286e74469, 0x23f5c465bd35bcd4353216dc9505df68324a27990df9825a242e1288e40a13bb, 0x35f409ce748af33c20a6ae693b8a48ba4623de9686f9834e22be4410e637d24f, 0xb962e5845c1db624532562597a99e2acc5e434b97d8db0725bdeddd71a98e737, 0x0f8364f99f43dd52b4cfa9e426c48f7b6ab18dc40a896e96a09eceebb3363afe, 0xa842746868da7644fccdbb07ae5e08c71a6287ab307c4f9717eadb414c9c99f4, 0xa59064c6b7fe7d2407792d99ed1218d2dc2f240185fbd8f767997438241b92e9, 0xb6ea0d58e8d48e05b9ff4d75b2ebe0bd9752c0e2691882f754be66cdec7628d3, 0xf16b78c9d14c52b2b5156690b6ce37a5e09661f49674ad22604c7d3755e564d1, 0xbfa8ef74e8a37cd64b8b4a4260c4fc162140603f9c2494b9cf4c1e13de522ed9, 0xf4b89f1776ebf30640dc5ec99e43de22136b6ef936a85193ef940931108e408a, 0xefb9a4555d495a584dbcc2a50938f6b9827eb014ffae2d2d0aae356a57894de8, 0x0627a466d42a26aca72cf531d4722e0e5fc5d491f4527786be4e1b641e693ac2, 0x7d10d21542de3d8f074dbfd1a6e11b3df32c36272891aae54053029d39ebae10, 0x0f21118ee9763f46cc175a21de876da233b2b3b62c6f06fa2df73f6deccf37f3, 0x143213b96f8519c15164742e2350cc66e814c9570634e871a8c1ddae4d31b6b5, 0x8d2877120abae3854e00ae8cf5c8c95b3ede10590ab79ce2be7127239507e18d, 0xaccd0005d59472ac04192c059ed9c10aea42c4dabec9e581f6cb10b261746573, 0x67bc8dd5422f39e741b9995e6e60686e75d6620aa0d745b84191f5dba9b5bb18, 0x11b8e95f6a654d4373cefbbac29a90fdd8ae098043d1969b9fa7885318376b34, 0x431a0b8a6f08760c942eeff5791e7088fd210f877825ce4dcabe365e03e4a65c, 0x704007f11bae513f428c9b0d23593fd2809d0dbc4c331009856135dafec23ce4, 0xc06dee39a33a05e30c522061c1d9272381bde3f9e42fa9bd7d5a5c8ef11ec6ec, 0x66b4157baaae85db0948ad72882287a80b286df2c40080b8da4d5d3db0a61bd2, 0xef1983b1906239b490baaaa8e4527f78a57a0a767d731f062dd09efb59ae8e3d, 0xf26d0d5c520cce6688ca5d51dee285af26f150794f2ea9f1d73f6df213d78338, 0x8b28838382e6892f59c42a7709d6d38396495d3af5a8d5b0a60f172a6a8940bd, 0x261a605fa5f2a9bdc7cffac530edcf976e7ea7af4e443b625fe01ed39dad44b6] compressed_lamport_pk = 0xdd635d27d1d52b9a49df9e5c0c622360a4dd17cba7db4e89bce3cb048fb721a5 child_sk = 20397789859736650942317412262472558107875392172444076792671091975210932703118 implementation python copyright copyright and related rights waived via cc0. citation please cite this document as: carl beekhuizen , "erc-2333: bls12-381 key generation [draft]," ethereum improvement proposals, no. 2333, september 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2333. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-141: designated invalid evm instruction ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-141: designated invalid evm instruction authors alex beregszaszi (@axic) created 2017-02-09 table of contents abstract motivation specification backwards compatibility copyright abstract an instruction is designated to remain as an invalid instruction. motivation the invalid instruction can be used as a distinct reason to abort execution. specification the opcode 0xfe is the invalid instruction. it can be used to abort the execution (i.e. duplicates as an abort instruction). backwards compatibility this instruction was never used and therefore has no effect on past contracts. copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), "eip-141: designated invalid evm instruction," ethereum improvement proposals, no. 141, february 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-141. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-191: signed data standard ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-191: signed data standard authors martin holst swende (@holiman), nick johnson created 2016-01-20 table of contents abstract motivation specification registry of version bytes example copyright abstract this erc proposes a specification about how to handle signed data in ethereum contracts. motivation several multisignature wallet implementations have been created which accepts presigned transactions. a presigned transaction is a chunk of binary signed_data, along with signature (r, s and v). the interpretation of the signed_data has not been specified, leading to several problems: standard ethereum transactions can be submitted as signed_data. an ethereum transaction can be unpacked, into the following components: rlp (hereby called rlpdata), r, s and v. if there are no syntactical constraints on signed_data, this means that rlpdata can be used as a syntactically valid presigned transaction. multisignature wallets have also had the problem that a presigned transaction has not been tied to a particular validator, i.e a specific wallet. example: users a, b and c have the 2/3-wallet x users a, b and d have the 2/3-wallet y user a and b submit presigned transactions to x. attacker can now reuse their presigned transactions to x, and submit to y. specification we propose the following format for signed_data 0x19 <1 byte version> . the initial 0x19 byte is intended to ensure that the signed_data is not valid rlp. for a single byte whose value is in the [0x00, 0x7f] range, that byte is its own rlp encoding. that means that any signed_data cannot be one rlp-structure, but a 1-byte rlp payload followed by something else. thus, any eip-191 signed_data can never be an ethereum transaction. additionally, 0x19 has been chosen because since ethereum/go-ethereum#2940 , the following is prepended before hashing in personal_sign: "\x19ethereum signed message:\n" + len(message). using 0x19 thus makes it possible to extend the scheme by defining a version 0x45 (e) to handle these kinds of signatures. registry of version bytes version byte eip description 0x00 191 data with intended validator 0x01 712 structured data 0x45 191 personal_sign messages version 0x00 0x19 <0x00> the version 0x00 has for the version specific data. in the case of a multisig wallet that perform an execution based on a passed signature, the validator address is the address of the multisig itself. the data to sign could be any arbitrary data. version 0x01 the version 0x01 is for structured data as defined in eip-712 version 0x45 (e) 0x19 <0x45 (e)> the version 0x45 (e) has for the version-specific data. the data to sign can be any arbitrary data. nb: the e in ethereum signed message refers to the version byte 0x45. the character e is 0x45 in hexadecimal which makes the remainder, thereum signed message:\n + len(message), the version-specific data. example the following snippets has been written in solidity 0.8.0. version 0x00 function signaturebasedexecution(address target, uint256 nonce, bytes memory payload, uint8 v, bytes32 r, bytes32 s) public payable { // arguments when calculating hash to validate // 1: byte(0x19) the initial 0x19 byte // 2: byte(0) the version byte // 3: address(this) the validator address // 4-6 : application specific data bytes32 hash = keccak256(abi.encodepacked(byte(0x19), byte(0), address(this), msg.value, nonce, payload)); // recovering the signer from the hash and the signature addressrecovered = ecrecover(hash, v, r, s); // logic of the wallet // if (addressrecovered == owner) executeontarget(target, payload); } copyright copyright and related rights waived via cc0. citation please cite this document as: martin holst swende (@holiman), nick johnson , "erc-191: signed data standard," ethereum improvement proposals, no. 191, january 2016. [online serial]. available: https://eips.ethereum.org/eips/eip-191. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1080: recoverable token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1080: recoverable token authors bradley leatherwood created 2018-05-02 discussion link https://ethereum-magicians.org/t/erc-1080-recoverabletoken-standard/364 table of contents simple summary abstract motivation specification recoverabletoken methods events rationale implementation copyright simple summary a standard interface for tokens that support chargebacks, theft prevention, and lost & found resolutions. abstract the following standard allows for the implementation of a standard api for tokens extending erc-20 or erc-791. this standard provides basic functionality to recover stolen or lost accounts, as well as provide for the chargeback of tokens. motivation to mitigate the effects of reasonably provable token or asset loss or theft and to help resolve other conflicts. ethereum’s protocol should not be modified because of loss, theft, or conflicts, but it is possible to solve these problems in the smart contract layer. specification recoverabletoken methods claimlost reports the lostaccount address as being lost. must trigger the accountclaimedlost event. after the time configured in getlostaccountrecoverytimeinminutes the implementer must provide a mechanism for determining the correct owner of the tokens held and moving the tokens to a new account. account recoveries must trigger the accountrecovered event. function claimlost(address lostaccount) returns (bool success) cancellostclaim reports the msg.sender’s account as being not being lost. must trigger the accountclaimedlostcanceled event. must fail if an account recovery process has already begun. otherwise, this method must stop a dispute from being started to recover funds. function claimlost() returns (bool success) reportstolen reports the current address as being stolen. must trigger the accountfrozen event. successful calls must result in the msg.sender’s tokens being frozen. the implementer must provide a mechanism for determining the correct owner of the tokens held and moving the tokens to a new account. account recoveries must trigger the accountrecovered event. function reportstolen() returns (bool success) chargeback requests a reversal of transfer on behalf of msg.sender. the implementer must provide a mechanism for determining the correct owner of the tokens disputed and moving the tokens to the correct account. must comply with sender’s chargeback window as value configured by setpendingtransfertimeinminutes. function chargeback(uint256 pendingtransfernumber) returns (bool success) getpendingtransfertimeinminutes get the time an account has to chargeback a transfer. function getpendingtransfertime(address account) view returns (uint256 minutes) setpendingtransfertimeinminutes sets the time msg.sender’s account has to chargeback a transfer. must not change the time if the account has any pending transfers. function setpendingtransfertime(uint256 minutes) returns (bool success) getlostaccountrecoverytimeinminutes get the time account has to wait before a lost account dispute can start. function getlostaccountrecoverytimeinminutes(address account) view returns (uint256 minutes) setlostaccountrecoverytimeinminutes sets the time msg.sender’s account has to sit before a lost account dispute can start. must not change the time if the account has open disputes. function setlostaccountrecoverytimeinminutes(uint256 minutes) returns (bool success) events accountrecovered the recovery of an account that was lost or stolen. event accountclaimedlost(address indexed account, address indexed newaccount) accountclaimedlostcanceled an account claimed as being lost. event accountclaimedlost(address indexed account) accountclaimedlost an account claimed as being lost. event accountclaimedlost(address indexed account) pendingtransfer a record of a transfer pending. event pendingtransfer(address indexed from, address indexed to, uint256 value, uint256 pendingtransfernumber) chargebackrequested a record of a chargeback being requested. event chargebackrequested(address indexed from, address indexed to, uint256 value, uint256 pendingtransfernumber) chargeback a record of a transfer being reversed. event chargeback(address indexed from, address indexed to, uint256 value, uint256 indexed pendingtransfernumber) accountfrozen a record of an account being frozen. must trigger when an account is frozen. event accountfrozen(address indexed reported) rationale a recoverable token standard can provide configurable safety for users or contracts who desire this safety. implementations of this standard will give users the ability to select a dispute resolution process on an opt-in basis and benefit the community by decreasing the necessity of consideration of token recovery actions. implementation pending. copyright copyright and related rights waived via cc0. citation please cite this document as: bradley leatherwood , "erc-1080: recoverable token [draft]," ethereum improvement proposals, no. 1080, may 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1080. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-2157: dtype storage extension decentralized type system for evm ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2157: dtype storage extension decentralized type system for evm authors loredana cirstea (@loredanacirstea), christian tzurcanu (@ctzurcanu) created 2019-06-28 discussion link https://github.com/ethereum/eips/issues/2157 requires eip-1900 table of contents simple summary abstract motivation specification typerootcontract typestoragecontract rationale backwards compatibility test cases implementation copyright simple summary this erc is an extension of erc-1900, proposing an optional storage extension for dtype, a decentralized type system, specifying a general abi for all storage contracts that contain type instances. abstract the storage extension will enable easy navigation and retrieval of type data that is intended to be of public use. this is possible through standardizing the abi of the dtype storage contracts, with the effect of having a deterministic path to a type instance record. this standardization enables a more effective on-chain and off-chain use of data and opens up possibilities for decentralized applications, enabling developers to build on top of public global data. motivation currently, ethereum does not have standardization of data addressability. this might not be needed for data that is meant to be quasi-private, however, it is needed for data that is meant for public consumption. erc-1900 has started standardizing data types for increasing interoperability between projects, but this is not enough if we want to build a global ecosystem. deterministic data addressability will enable anyone to build upon the same public data sets, off-chain or on-chain. it is true that with erc-1900, blockchain data analysis and type-specific data retrieval will be possible off-chain, but this implies relying on centralized data caches (blockchain explorers) or maintaining your own data cache. moreover, this option does not allow on-chain standardization on data retrieval paths, therefore limiting the type of on-chain interoperable operations that can be done. having a clear way of retrieving data, instead of analyzing the blockchain for contracts that have a certain type in their abi or bytecode, will make development easier and more decentralized for applications that target global data on specific types. for example, a decentralized market place can be built on top of some marketplace-specific types, and by knowing exactly where the type data is stored, it is easy to create custom algorithms that provide the user with the product information they seek. everyone has access to the data and the data path is standardized. moreover, by standardizing storage contract interfaces, abi inference is possible. the common interface, together with the dtype registry will provide all the data needed to reconstruct the abi. this system can be extended with access and mutability control later on, in a future proposal. access and mutability control will be necessary for public-use global systems. moreover, we can have a homogeneous application of permissions across system components. this is not detailed in the present proposal. another use case is data bridges between ethereum shards or between ethereum and other chains. data syncing between shards/chains can be done programmatically, across data types (from various projects). imagine a user having a public profile/identity contract on one chain, wishing to move that profile on ethereum. by supporting the origin chain types and having a standardized storage mechanism, data moving processes will be the same. this pattern of separating data type definitions and storage allows developers to create functional programming-like patterns on ethereum, even though languages such as solidity are not functional. specification typerootcontract erc-1900 defines a contractaddress field in the type metadata. for the limited purpose of erc-1900, this field contains the value of the ethereum type library in which the type definition exists. for the purpose of this erc, the contractaddress will contain the etherereum address of a typerootcontract. contract typerootcontract { address public libraryaddress; address public storageaddress; constructor(address _library, address _storage) public { libraryaddress = _library; storageaddress = _storage; } } libraryaddress ethereum address of the type definition library, from erc-1900 storageaddress ethereum address of the type data storage contract typestoragecontract this contract will use the type library to define the internal data stored in it. each record will be a type instance, addressable by a primary identifier. the primary identifier is calculated by the type library’s getidentifier function, based on the type instance values. we propose a solidity crud pattern, as described in https://medium.com/robhitchens/solidity-crud-part-1-824ffa69509a, where records can also be retrieved using their index a monotonically increasing counter. an stub implementation for the typestoragecontract would look like: import './typealib.sol'; contract typeastorage { using typealib for typealib.typea; bytes32[] public typeindex; mapping(bytes32 => type) public typestruct; struct type { typealib.typea data; uint256 index; } event lognew(bytes32 indexed identifier, uint256 indexed index); event logupdate(bytes32 indexed identifier, uint256 indexed index); event logremove(bytes32 indexed identifier, uint256 indexed index); function insert(typealib.typea memory data) public returns (bytes32 identifier); function insertbytes(bytes memory data) public returns (bytes32 identifier); function remove(bytes32 identifier) public returns(uint256 index); function update(bytes32 identifier, typealib.typea memory data) public returns(bytes32 identifier) function isstored(bytes32 identifier) public view returns(bool stored); function getbyhash(bytes32 identifier) public view returns(typealib.typea memory data); function getbyindex(uint256 index) public view returns(typealib.typea memory data); function count() public view returns(uint256 counter); } rationale we are now thinking about a building block as a smart contract with an encapsulated object that contains state changing functions that are only understood from within. this is more akin to object-oriented programming and poses interoperability and scalability issues. not necessarily for an individual project, but for a global ethereum os. this is why we are proposing to separate data from business logic and data structure definitions. when you have public aggregated data, categorized on each type, anyone can build tools on top of it. this is a radical change from the closed or dispersed data patterns that we find in web2. we have chosen to define a typerootcontract instead of extending the dtype registry with fields for the typestorage contract, because this approach enables easier interface updates in the future. it is more extensible. the storage pattern used for dtype itself and all the type storage contracts can be the same. this lowers the cost of building, testing and auditing the code. the typestoragecontract pattern should ensure: type instance addressability by the primary identifier a way to retrieve all records from the contract counting the number of records backwards compatibility this proposal does not affect existent ethereum standards or implementations. it uses the present experimental version of abiencoderv2. test cases will be added. implementation an in-work implementation can be found at https://github.com/pipeos-one/dtype/tree/master/contracts/contracts. this proposal will be updated with an appropriate implementation when consensus is reached on the specifications. copyright copyright and related rights waived via cc0. citation please cite this document as: loredana cirstea (@loredanacirstea), christian tzurcanu (@ctzurcanu), "erc-2157: dtype storage extension decentralized type system for evm [draft]," ethereum improvement proposals, no. 2157, june 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2157. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. a message from stephan tual | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search a message from stephan tual posted by stephan tual on september 3, 2015 organizational to the wonderful ethereum community, you often heard me say at conferences that ethereum was not a company, a foundation, an implementation, or an individual. ethereum is both an idea and an ideal, encompassing the first censorship-resistant network build specifically to enable those who need it the most to safely trade, privately self-organise and freely communicate, rather than relying on the crippled walled garden handed out by the powers that be. due to divergence in personal values, eth/dev and i have mutually decided to part ways. i of course intend to continue promoting the ethereum ideals and bring about a world-class, mainstream platform to build a new breed of decentralized applications. from now on, you'll be able to email me at stephan@ursium.com, read my articles and tutorials on blog.ursium.com, or follow me at @stephantual. i want to thank each and everyone of you for your incredible enthusiasm and passion, helping pioneer what i believe is the most significant piece of software concept the world has ever seen. your commitment inspired me, and on many occasions helped me keep going through a year and half of incredibly hard work. see you very soon, stephan previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-3044: adds `basefee` to `eth_getblockbynumber` ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3044: adds `basefee` to `eth_getblockbynumber` authors abdelhamid bakhta (@abdelhamidbakhta) created 2020-10-14 discussion link https://ethereum-magicians.org/t/eip-3044-add-basefee-to-eth-getblockbynumber/4828 requires eip-1474, eip-1559 table of contents simple summary abstract motivation specification eth_getblockbynumber rationale backwards compatibility security considerations copyright simple summary add basefee field to eth_getblockbynumber rpc endpoint response. abstract adds basefee property to the eth_getblockbynumber json-rpc request result object. this property will contain the value of the base fee for any block after the eip-1559 fork. motivation eip-1559 introduces a base fee per gas in protocol. this value is maintained under consensus as a new field in the block header structure. users may need value of the base fee at a given block. base fee value is important to make gas price predictions more accurate. specification eth_getblockbynumber description returns information about a block specified by number. every block returned by this endpoint whose block number is before the eip-1559 fork block must not include a basefee field. every block returned by this endpoint whose block number is on or after the eip-1559 fork block must include a basefee field. parameters parameters remain unchanged. returns for the full specification of eth_getblockbynumber see eip-1474. add a new json field to the result object for block headers containing a base fee (post eip-1559 fork block). {quantity} basefee base fee for this block example # request curl -x post --data '{ "id": 1559, "jsonrpc": "2.0", "method": "eth_getblockbynumber", "params":["latest", true] }' # response { "id": 1559, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extradata": "0x0000000000000000000000000000000000000000000000000000000000000000", "basefee": "0x7" "gaslimit": "0x9f759", "gasused": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsbloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parenthash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateroot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totaldifficulty": "0x027f07", "transactions": [] "transactionsroot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [] } } rationale the addition of a single parameter instead of introducing a whole new endpoint was the simplest change that would be easiest to get integrated. for backward compatibility we decided to not include the base fee in the response for pre-1559 blocks. backwards compatibility backwards compatible. calls related to block prior to eip-1559 fork block will omit the base fee field in the response. security considerations the added field (basefee) is informational and does not introduce technical security issues. copyright copyright and related rights waived via cc0. citation please cite this document as: abdelhamid bakhta (@abdelhamidbakhta), "eip-3044: adds `basefee` to `eth_getblockbynumber` [draft]," ethereum improvement proposals, no. 3044, october 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3044. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-7045: increase max attestation inclusion slot ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: core eip-7045: increase max attestation inclusion slot increases max attestaton inclusion slot to the last slot in `n+1` where `n` is the epoch containing the attestation's slot. authors danny ryan (@djrtwo) created 2023-05-18 last call deadline 2024-02-15 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification constants execution layer consensus layer rationale extended max inclusion slot removal of inclusion_delay consideration for target reward backwards compatibility security considerations copyright abstract increases max attestation inclusion slot from attestation.slot + slots_per_epoch to the last slot of epoch n+1 where n is the epoch containing the attestation slot. this increase is critical to the current lmd-ghost security analysis as well as the confirmation rule. motivation attestations can currently be included after some minimum delay (1 slot on mainnet) up until slots_per_epoch slots after the slot the attestation was created in. this rolling window of one epoch was decided upon during phase 0 because the equal inclusion window for any attestation was assessed as “fair”. the alternative considered path was to allow inclusion during the current and next epoch which means attestations created during the start of an epoch have more potential slots of inclusion than those at the end of the epoch. since this decision, it has become apparent that the alternative design is critical for current lmd-ghost security proofs as well as a new confirmation rule (which will allow for block confirmations in approximately 3-4 slots in normal mainnet conditions). this specification thus increases the max inclusion slot for attestations in accordance with the learned security proof and confirmation rule needs. specification constants name value comment fork_timestamp tbd mainnet execution layer this requires no changes to the execution layer. consensus layer specification changes are built into the consensus specs deneb upgrade. the specification makes two minor changes to the state transition function: modify process_attestation to not have an upper bound on the slot check and instead define the inclusion range via the minimum slot as well as the target epoch being in either current or previous epoch. modify get_attestation_participation_flag_indices to set the timely_target_flag without consideration of inclusion_delay to ensure that the extended inclusion attestations have a non-zero reward. additionally, the specification modifies the attestation and aggregate attestation gossip conditions to allow for gossip during this extended range. rationale extended max inclusion slot as discussed in the motivation, extending this max inclusion slot to the end of the next epoch is critical for lmd-ghost security proofs and confirmation rule. removal of inclusion_delay consideration for target reward previously, get_attestation_participation_flag_indices would only set the timely_target_flag (and thus reward for an attestation with correct target vote) if the attestation was included within a slots_per_epoch window. the inclusion_delay consideration for this flag is removed to ensure that whatever the valid inclusion window is for an attestation, it can receive a baseline non-zero reward for correct target. this ensures that clients will still attempt to pack such attestations into blocks which is important for the security analysis. note, this was the intended behavior with the previously defined range which was equivalent to the max. backwards compatibility this eip introduces backwards incompatible changes to the block validation rule set on the consensus layer and must be accompanied by a hard fork. security considerations this improves lmd-ghost security as well as enables a fast confirmation rule. there are no known negative impacts to security. copyright copyright and related rights waived via cc0. citation please cite this document as: danny ryan (@djrtwo), "eip-7045: increase max attestation inclusion slot [draft]," ethereum improvement proposals, no. 7045, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7045. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1581: non-wallet usage of keys derived from bip-32 trees ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1581: non-wallet usage of keys derived from bip-32 trees a derivation path structure for bip32 trees to generate key pairs not meant to hold crypto assets. authors michele balistreri (@bitgamma) created 2018-11-13 discussion link https://ethereum-magicians.org/t/non-wallet-usage-of-keys-derived-from-bip-32-trees/1817 table of contents abstract motivation specification path levels purpose/coin type/subpurpose key type key index rationale copyright abstract bip32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. bip32 and bip44 defines the usage of these keys as wallets. in this eip we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing bip44 compatible wallets. motivation applications interacting with the blockchain often make use of additional, non-blockchain technologies to perform the task they are designed for. for privacy and security sensitive mechanisms, sets of keys are needed. reusing keys used for wallets can prove to be insecure, while keeping completely independent keys make backup and migration of the full set of credentials more complex. defining a separate (from bip44 compliant wallets) derivation branch allows combining the security of independent keys with the convenience of having a single piece of information which needs to be backup or migrated. specification path levels we define the following levels in bip32 path: m / purpose' / coin_type' / subpurpose' / key_type' / key_index apostrophe in the path indicates that bip32 hardened derivation is used. this structure follows the bip43 recommendations and its amendments for non-bitcoin usage. each level has a special meaning, described in the chapters below. purpose/coin type/subpurpose this part is constant and set to m / 43' / 60' / 1581', meaning bip 43 -> ethereum -> this eip. all subtrees under this prefix are the scope of this eip. key type describes the purpose for which the key is being used. key types should be generic. “instant messaging” is a good example whereas “whisper” is not. the reason is that you want to be able to use the same identity across different services. key types are defined at: tbd hardened derivation is used at this level. key index the key index is a field of variable length identifying a specific key. in its simplest case, it is a number from 0 to 2^31-1. if a larger identifier is desired (for example representing a hash or a guid), the value must be split across several bip32 nesting levels, most significant bit first and left aligned, bit-padded with 0s if needed. all levels, except the last one must used hardened key derivation. the last level must use public derivation. this means that every level can carry 31-bit of the identifier to represent. as an example, let’s assume we have a key with key type 4’ and a key_index representing a 62-bit id represented as hexadecimal 0x2bcdeffedcbaabcd the complete keypath would be m / 43' / 60' / 1581' / 4' / ‭1469833213‬' / ‭1555737549‬. if you are using random identifiers, it might be convenient to generate a conventional guid, for example 128-bit just fix the value of the most significant bit of each 32-bit word to 1 for all of them, except the last one which will be 0. rationale the structure proposed above follows the bip43 generic structure and is similar to the widely adopted bip44 specification. copyright copyright and related rights waived via cc0. citation please cite this document as: michele balistreri (@bitgamma), "erc-1581: non-wallet usage of keys derived from bip-32 trees [draft]," ethereum improvement proposals, no. 1581, november 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1581. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. the ethereum launch process | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search the ethereum launch process posted by vinay gupta on march 3, 2015 research & development i’m vinay gupta, the newly minted release coordinator for ethereum. i’ve been working with the comms team on strategy, and have now come aboard to help smooth the release process (some of the content in this blog is out of date, please see this link for the most up to date information on ethereum). i’ll be about 50/50 on comms and on release coordination. a lot of that is going to be about keeping you updated on progress: new features, new documentation, and hopefully writing about great new services you can use, so it’s in the hinterland between comms and project management. in theory, once i’m up to speed, i should be providing you with the answers to the question: “what’s going on?” but give me some time, because getting up to speed on all of this is nontrivial. we have a very large development team working with very advanced and often quite complex new technology, and keeping everybody up to date on that simultaneously is going to be tricky. to do that well, i have to actually understand what’s going on at quite a technical level first. i have a lot to wrap my head around. i was a 3d graphics programmer through the 1990s, and have a reasonably strong grounding in financial cryptography (i was, and i am not ashamed to admit it, a cypherpunk in those days). but we have a 25-30 person team working in parallel on several different aspects of ethereum, so... patience please while i master the current state of play, so that i can communicate about what’s changing as we move forwards. it’s a lot of context to acquire, as i’m sure you all know if there’s an occasional gaffe as i get oriented, forgive me! i’ve just come back from switzerland, where i got to meet a lot of the team, my “orientation week” being three days during the release planning meetings. gav writes in some detail about that week here, so rather than repeat gav, read his post, and i’ll press on to tell you what was on that release white board. there is good news, there is bad news, but above all, there is a release schedule. there will be another blog post with much more detail about the release schedule for the first live ethereum network shortly likely by the end of this week, as the developer meeting that gav mentions in his post winds up and the conclusions are communicated. that’s the post which will give you timelines you can start firing up your mining rigs to, feature lists, and so on. until then, let me lay out roughly what the four major steps in the release process will look like and we can get into detail soon. let’s lay out where we are first: ethereum is a sprawling project with many teams in many countries implementing the same protocol in several different language versions so it can be integrated into the widest possible range of other systems/ecologies, and to provide long term resilience and future-proofing. in addition to that broad effort, there are several specific applications/toolchains to help people view, build and interact with ethereum: mist, mix, alethzero and so on. starting quite soon, and over the next few months, a series of these tools will be stood up as late alpha, beta, ready for general use and shipped. because the network is valuable, and the network is only as secure as the software we provide, this is going to be a security-led not schedule-led process. you want it done right, we want it done right, and this is one of the most revolutionary software projects ever shipped. while you’re waiting for the all singing, all dancing cern httpd + ncsa mosaic combo, the “we have just launched the future of the internet” breakthrough system, we will be actually be releasing the code and the tools in layers. we are standing up the infrastructure for a whole new web a piece at a time: server first, plus tool chain, and then the full user experience rich client. this makes sense: a client needs something to connect to, so the server infrastructure has to come first. an internet based on this metacomputer model is going to be a very different place, and getting a good interface to that is going to present a whole new set of challenges. there’s no way to simply put all the pieces together and hope it clips into place like forming an arch by throwing bricks in the air: we need scaffolding, and precise fit. we get that by concentrating on the underlying technical aspects for a while, including mining, the underlying network and so on, and then as that is widely deployed, stable and trusted, we will be moving up the stack towards the graphical user interface via mist in the next few months. none of these pieces stand alone, either: the network needs miners and exchanges, and it takes people time to get organized to do that work properly. the mist client needs applications, or it’s a bare browser with nothing to connect to, and it takes people time to write those applications. each change, each step forwards, involves a lot of conversations and support as we get people set up with the new software and help them get their projects off the ground: the whole thing together is an ecology. each piece needs its own time, its own attention. we have to do this in phases for all of these reasons, and more. it took bitcoin, a much less complex project, several years to cover that terrain: we have a larger team, but a more complex project. on the other hand, if you’re following the github repositories, you can see how much progress is being made, week by week, day by day, so... verify for yourself where we are. so, now we’ve all got on the same page on real world software engineering, let’s actually look at phases of this release process! release step one: frontier frontier takes a model familiar to bitcoiners, and stands it up for our initial release. frontier is the ethereum network in its barest form: an interface to mine ether, and a way to upload and execute contracts. the main use of frontier on the launch trajectory is to get mining operations and ether exchanges running, so the community can get their mining rigs started, and to start to establish a “live” environment where people can test dapps and acquire ether to upload their own software into ethereum. this is “no user interface to speak of” command line country, and you will be expected to be quite expert in the whole ethereum world model, as well as to have substantial mastery of the tools at your disposal. however, this is not a test net: this is a frontier release. if you are equipped, come along! do not die of dysentery on the way. frontier showcases three areas of real utility: you can mine real ether, at 10% of the normal ether issuance rate, 0.59 ether per block reward, which can be spent to run programs or exchange for other things, as normal this real ether (this was not the case at launch frontier block reward is 5 ether per block, and will remain that amount until casper). you can exchange ether for bitcoin, or with other users, if you need ether to run code etc. if you already bought ether during the crowd sale, and you are fully conversant with the frontier environment, you can use it on the frontier network. we do not recommend this, but have a very substantial security-and-recovery process in place to make it safer see below we will migrate from frontier to homestead once frontier is fully stable in the eyes of the core devs and the auditors: when we are ready to move to homestead, the release after frontier, the frontier network will be shut down; ether values in wallets will be transferred, but state in contracts is will likely be erased (more information to follow on this in later blog posts) switchover to the new network will be enforced by “thebomb” this is very early release software: feature complete within these boundaries, but with a substantial risk of unexpected behaviours unseen in either the test net or the security review. and it’s not just us that will be putting new code into production: contracts, exchanges, miners, everybody else in the ecosystem will be shipping new services. any one of those components getting seriously screwed up could impact a lot of users, and we want to shake bugs out of the ecosystem as a whole, not simply our own infrastructure: we are all in this together. however, to help you safeguard your ether, we have the following mechanisms planned (more details from the developers will follow soon as the security model is finalised): if you do not perform any transactions, we guarantee 100% your ether will not be touched and will be waiting for you once we move beyond frontier if you perform transactions, we guarantee 100% that any ether you did not spend will will be available to you once we move beyond frontier not be touched ether you spend will not fall through cracks into other people’s pockets or vanish without a trace: in the unlikely event that this happens, you have 24 hours to inform us, and we will freeze the network, return to the last good state, and start again with the bug patched yes, this implies a real risk of network instability: everything possible has been done to prevent this, but this is a brand new aeroplane take your parachute! we will periodically checkpoint the network to show that neither user report nor automated testing has reported any problems. we expect the checkpoints will be around once daily, with a mean of around 12 hours of latency exchanges etc. will be strongly encouraged to wait for checkpoints to be validated before sending out payments in fiat or bitcoin. ethereum will provide explicit support to aid exchanges in determining what ether transactions have fully cleared over the course of the next few weeks several pieces of software have to be integrated to maintain this basket of security features so we can allow genesis block ether on to this platform without unacceptable risks. building that infrastructure is a new process, and while it looks like a safe, sane and conservative schedule, there is always a chance of a delay as the unknown unknown is discovered either by us, the bug bounty hunters or by the security auditors. there will be a post shortly which goes through this release plan in real technical detail, and i’ll have a lot of direct input from the devs on that post, so for now take this with a pinch of salt and we will have hard details and expected dates as soon as possible. release step two: homestead homestead is where we move after frontier. we expect the following three major changes. ether mining will be at 100% rather than 10% of the usual reward rate (frontier/homestead block reward will remain 5 ether) checkpointing and manual network halts should never be necessary, although it is likely that checkpointing will continue if there is a general demand for it we will remove the severe risk warning from putting your ether on the network, although we will not consider the software to be out of beta until metropolis still command line, so much the same feature set as frontier, but this one we tell you is ready to go, within the relevant parameters. how long will there be between frontier and homestead? depends entirely on how frontier performs: best case is not less than a month. we will have a pretty good idea of whether things are going smoothly or not from network review, so we will keep you in the loop through this process. release step three: metropolis metropolis is when we finally officially release a relatively full-featured user interface for non-technical users of ethereum, and throw the doors open: mist launches, and we expect this launch to include a dapp store and several anchor tenant projects with full-featured, well-designed programs to showcase the full power of the network. this is what we are all waiting for, and working towards. in practice, i suspect there will be at least one, and probably two as-yet-unnamed steps between homestead and metropolis: i’m open to suggestions for names (write to vinay[at]ethdev.com). features will be sensible checkpoints on the way: specific feature sets inside of mist would be my guess, but i’m still getting my head around that, so i expect we will cross those bridges after homestead is stood up. release step four: serenity there’s just one thing left to discuss: mining. proof of work implies the inefficient conversion of electricity into heat, ether and network stability, and we would quite like to not warm the atmosphere with our software more than is absolutely necessary. short of buying carbon offsets for every unit of ether mined (is that such a bad idea?), we need an algorithmic fix: the infamous proof of stake. switching the network from proof of work to proof of stake is going to require a substantial switch, a transition process potentially much like the one between frontier and homestead. similar rollback measures may be required, although in all probability more sophisticated mechanisms will be deployed (e.g. running both mechanisms together, with proof of work dominant, and flagging any cases where proof of stake gives a different output.) this seems a long way out, but it’s not as far away as all that: the work is ongoing. proof of work is a brutal waste of computing power like democracy*, the worst system except all the others (*voluntarism etc. have yet to be tried at scale). freed from that constraint, the network should be faster, more efficient, easier for newcomers to get into, and more resistant to cartelization of mining capacity etc. this is probably going to be almost as big a step forwards as putting smart contracts into a block chain in the first place, by the time all is said and done. it is a ways out. it will be worth it. timelines as you have seen since the ether sale, progress has been rapid and stable. code on the critical path is getting written, teams are effective and efficient, and over-all the organization is getting things done. reinventing the digital age is not easy, but somebody has to do it. right now that is us. we anticipate roughly one major announcement a month for the next few months, and then a delay while metropolis is prepared. there will also be devcon one, an opportunity to come, learn the practical business of building and shipping dapps, meet fellow developers, potential investors, and understand the likely shape of things to come. we will give you information about each release in more detail as each release approaches, but i want to give you the big overview of how this works and where we are going, fill in some of the gaps, highlight what is changing, both technically and in our communications and business partnership, and present you with an overview of what the summer is going to be like as we move down the path towards serenity, another world changing technology. i’m very glad to be part of this process. i’m a little at sea right now trying to wrap my head around the sheer scope of the project, and i’m hoping to actually visit a lot of the development teams over the summer to get the stories and put faces to names. this is a big, diverse project and, beyond the project itself, the launch of a new sociotechnical ecosystem. we are, after all, a platform effort: what’s really going to turn this into magic is you, and the things you build on top of the tools we’re all working so hard to ship. we are making tools for tool-makers. vinay signing off for now. more news soon! previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-4520: multi-byte opcodes prefixed by eb and ec. ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-4520: multi-byte opcodes prefixed by eb and ec. reserve `0xeb` and `0xec` for usage as extended opcode space. authors brayton goodall (@spore-druid-bray), mihir faujdar (@uink45) created 2021-12-01 discussion link https://ethereum-magicians.org/t/multi-byte-opcodes/7681 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract reserve 0xeb and 0xec for usage as extended opcode space. motivation it would be convenient to introduce new opcodes that are likely to be infrequently used, whilst also being able to have greater than 256 opcodes in total. as a single byte opcode is half the size of a double byte opcode, the greatest efficiency in code sizes will be one where frequently used opcodes are single bytes. two prefix bytes are used to accommodate up to 510 double byte opcodes. specification for example, a new arithmetic opcode may be allocated to 0xec 01(add), and a novel opcode may be introduced at 0xeb f4(delegatecall). triple byte opcodes may be doubly-prefixed by 0xeb eb, 0xec ec, 0xeb ec and 0xec eb. it is possible to allocate experimental opcodes to this triple-byte space initially, and if they prove safe and useful, they could later be allocated a location in double-byte or single-byte space. only 0xeb eb, 0xec ec, 0xec ec, and 0xeb ec may be interpreted as further extensions of the opcode space. 0xeb and 0xec do not themselves affect the stack or memory, however opcodes specified by further bytes may. if a multi-byte opcode is yet to be defined, it is to be treated as invalid rather than as a nop, as per usual for undefined opcodes. rationale it was considered that two prefix bytes rather than one would be adequate for reservation as extension addresses. both 0xeb and 0xec were chosen to be part of the e-series of opcodes. for example, the 0xef byte is reserved for contracts conforming to the ethereum object format. by having unassigned opcodes for extending the opcode space, there will be a lower risk of breaking the functionalities of deployed contracts compared to choosing assigned opcodes. backwards compatibility previous usage of 0xeb and 0xec may result in unexpected behaviour and broken code. security considerations there are no known security considerations. copyright copyright and related rights waived via cc0. citation please cite this document as: brayton goodall (@spore-druid-bray), mihir faujdar (@uink45), "eip-4520: multi-byte opcodes prefixed by eb and ec. [draft]," ethereum improvement proposals, no. 4520, december 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4520. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-7039: scheme-handler discovery option for wallets ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: interface eip-7039: scheme-handler discovery option for wallets using custom protocol handlers to initiate connections between web pages and wallets. authors sam wilson (@samwilsn) created 2023-05-15 discussion link https://ethereum-magicians.org/t/shadow-a-scheme-handler-discovery-option-for-wallets/14330 requires eip-1193 table of contents abstract motivation specification initiating a connection communicating on an established connection icon images rationale backwards compatibility security considerations copyright abstract this proposal (affectionately known as shadow) is an alternative to eip-1193 for wallet discovery in web browsers that requires no special permissions. web pages intending to open a connection to a wallet inject an iframe tag pointing at a well-known scheme. communication between the page and the wallet uses the postmessage api. motivation current wallet discovery methods (eg. window.ethereum) only support one active wallet at a time, and require browser extensions to request broad permissions to modify web pages. ideally users should be able to have multiple wallets active, and choose between them at runtime. this not only results in an improved user experience but also reduces the barrier to entry for new browser extensions as users are no longer forced to only install one browser extension at a time. with shadow, and unlike other recent proposals, browser extensions do not need blanket content_scripts or any permissions at all. furthermore, any web page (and not just browser extensions) can register a handler for a protocol. that means better support for pure web wallets, native executable wallets, and hardware wallets. as long as a wallet can serve a page securely, it can register itself as a handler. 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. initiating a connection to initiate a connection to a provider, a web page should: add an event listener to window for the "message" event (or set window.onmessage.) create an iframe tag with a src attribute value of web+evm://; then attach the iframe to the dom. wait for a "message" event with a non-nullish source equal to the iframe’s contentwindow. save the first port from the message event for further communication. this is referred to as the “primary port.” the event received in step 3 may contain additional information about the provider. if present, the event data shall satisfy the following typescript interface: interface providerinfo { name: string; icon: string; } where: name is the human-readable name of the provider; and icon is a uri pointing at an image. see icon images. communicating on an established connection the web page and wallet may make requests of the other. the party making the request is known as the requester, and the replying party is known as the responder. a requester may make requests of the responder by sending a message (using postmessage) on the primary port. the message may include a messageport as the first item of the message’s transfer list to receive a reply. this port is known as a “reply port.” the message’s data must satisfy eip-1193’s requestarguments interface, and shall be interpreted as described there. the responder shall respond by posting a single message to the reply port, if a reply port was transferred. the message’s data shall satisfy the following typescript interface, where providerrpcerror is defined in eip-1193: interface response { result?: unknown; error?: providerrpcerror; } exactly one of result or error shall be present on the response. if present, result shall be equivalent to the result field of the named json-rpc method’s response. error objects should follow the recommendations set out in eip-1193. a request without a transferred reply port shall not be considered an error, even if a reply would have been sent. icon images rationale instead of directly using the iframe.contentwindow’s message port, shadow transfers a message port in the first message. this allows the iframe, in some specific scenarios, to completely hand off communication, so the web page and the provider communicate directly, without any proxying in the iframe. backwards compatibility while not backwards compatible with eip-1193, this proposal uses extremely similar data structures to make the transition as painless as possible. it is possible to implement an eip-1193 compatible provider using this proposal like so: security considerations both providers and web pages must verify the origin of messages before trusting them. copyright copyright and related rights waived via cc0. citation please cite this document as: sam wilson (@samwilsn), "eip-7039: scheme-handler discovery option for wallets [draft]," ethereum improvement proposals, no. 7039, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7039. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5022: increase price of sstore from zero to non-zero to 40k gas ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-5022: increase price of sstore from zero to non-zero to 40k gas authors green (@greenlucid) created 2022-04-20 discussion link https://ethereum-magicians.org/t/eip-proposal-increase-cost-of-sstore-from-20k-to-x-when-creating-new-storage/7614 table of contents abstract motivation why not also raise the cost of non-zero to non-zero? why not also increase the gas refund from setting non-zero to zero? why not a better state solution? why was that specific amount chosen? is this too distruptive? specification backwards compatibility abstract increase the price of the sstore opcode from 20_000 gas to 40_000 gas when the original slot is zero and the resultant slot is non-zero. motivation the cost of creating a piece of new state increases as state is larger. however, the price for creating every new storage slot has not increased. all resources are merged into the same pricing mechanism. if the price for creating new storage slots is fixed, then it needs to be manually changed. one of the main reasons for not increasing gas limit is the increase of state. in that regard, because the cost of creating storage is higher than its price, all the users of all the other opcodes are subsidizing the creation of state. if state creation was more precisely priced, raising gas limit would be more feasible, and would benefit the users. rationale why not also raise the cost of non-zero to non-zero? rewriting storage does not affect state growth, which is the main issue this eip is addressing. rewriting storage may also be underpriced. increasing the price of state growth will, at least, incentivize developers to reuse storage instead. why not also increase the gas refund from setting non-zero to zero? more discussion is needed on this. why not a better state solution? whereas solutions like state rent, or state expiry have been researched for a long time, they will not be ready on the short to medium term. so, it is desirable to patch pricing for the short term. opcode repricing has been done before, so it should not impose a large development time investment for clients. why was that specific amount chosen? the current pricing was made off a naive approach of benchmarking opcodes in a laptop. not only it did not consider the long term problem of having the same price for a resource that costs more over time, the benchmark itself was wrong. this price is closer to what the naive original benchmark should have been. it could go higher, but that may be too disruptive. is this too distruptive? this change will severely impact the gas cost of many applications. the network does not have to subsidize state growth at the expense of more expensive regular transactions, so even if it is too disruptive, it will increase the health of the network. specification constant value fork_block tbd new_storage_price 40_000 for blocks where block.number >= fork_block, a new gas schedule applies. make sstore_set_gas, the price when a slot is set from zero to non-zero, equal new_storage_price. all other costs remain the same. backwards compatibility contracts that depend on hardcoded gas costs will break if they create state. it is a gas schedule change, so transactions from an epoch before fork_block should be treated with previous gas costs. implementation https://github.com/ethereum/go-ethereum/pull/24725 security considerations todo citation please cite this document as: green (@greenlucid), "eip-5022: increase price of sstore from zero to non-zero to 40k gas [draft]," ethereum improvement proposals, no. 5022, april 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5022. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1051: overflow checking for the evm ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1051: overflow checking for the evm authors nick johnson created 2018-05-02 discussion link https://ethereum-magicians.org/t/eip-arithmetic-overflow-detection-for-the-evm/261 table of contents abstract motivation specification rationale backwards compatibility test cases implementation copyright abstract this eip adds overflow checking for evm arithmetic operations, and two new opcodes that check and clear the overflow flags. motivation the correct functioning of many contracts today is dependent on detecting and preventing overflow of arithmetic operations. since the evm operates on mod 2^256 integers and provides no built-in overflow detection or prevention, this requires manual checks on every arithmetic operation. in the interests of facilitating efficient and secure contracts, we propose new opcodes that permit efficient detection of overflows, which can be checked periodically rather than after each operation. specification two new flags are added to the evm state: overflow (ovf) and signed overflow (sovf). the ovf flag is set in the following circumstances: when an add (0x01) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 1. when a sub (0x03) opcode, with both inputs treated as unsigned integers, produces an ideal output less than 0. when a mul(0x02) opcode, with both inputs treated as unsigned integers, produces an ideal output in excess of 2^256 1. the sovf flag is set whenever the ovf flag is set, and additionally in the following circumstances: when an add opcode with both inputs having the same msb results in the output having a different msb (eg, (+a) + (+b) = (-c) or (-a) + (-b) = (+c)). when a sub opcode occurs and the result has the same msb as the subtractand (second argument) (eg, (+a) (-b) = (-c) or (-a) (+b) = (+c). when a mul opcode with both inputs being positive has a negative output. when a mul opcode with both inputs being negative has a negative output. when a mul opcode with one negative input and one positive input has a positive output. a new opcode, ofv is added, with number 0x0c. this opcode takes 0 arguments from the stack. when executed, it pushes 1 if the ovf flag is set, and 0 otherwise. it then sets the ovf flag to false. a new opcode, sovf is added, with number 0x0d. this opcode takes 0 arguments from the stack. when executed, it pushes 1 if the sovf flag is set, and 0 otherwise. it then sets the sovf flag to false. rationale any change to implement overflow protection needs to preserve behaviour of existing contracts, which precludes many changes to the arithmetic operations themselves. one option would be to provide an opcode that enables overflow protection, causing a throw or revert if an overflow happens. however, this limits the manner in which overflows can be handled. instead, we replicate functionality from real world cpus, which typically implement ‘carry’ and ‘overflow’ flags. separate flags for signed and unsigned overflow are necessary due to the fact that a signed overflow may not result in an unsigned overflow. backwards compatibility this eip introduces no backwards compatibility issues. test cases tbd implementation tbd copyright copyright and related rights waived via cc0. citation please cite this document as: nick johnson , "eip-1051: overflow checking for the evm [draft]," ethereum improvement proposals, no. 1051, may 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1051. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3455: sudo opcode ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-3455: sudo opcode a new opcode is introduced to allow calling from an arbitrary sender address. authors william morriss (@wjmelements), baptiste vauthey (@thabaptiser) created 2021-04-01 discussion link https://ethereum-magicians.org/t/eip-3455-sudo-opcode/5860 table of contents abstract motivation specification rationale security considerations copyright abstract a new opcode, sudo, is introduced with the same parameters as call, plus another parameter to specify the sender address. motivation there are many use cases for being able to set the sender. many tokens are stuck irretrievably because nobody has the key for the owner address. in particular, at address zero there is approximately 17 billion usd in tokens and ether, according to etherscan. with sudo, anyone could free that value, leading to an economic boom that would end poverty and world hunger. instead it is sitting there idle like the gold in fort knox. sudo fixes this. it is a common mistake to send erc-20 tokens to the token address instead of the intended recipient. this happens because users paste the token address into the recipient fields. currently there is no way to recover these tokens. sudo fixes this. many scammers have fraudulently received tokens and eth via trust-trading. their victims currently have no way to recover their funds. sudo fixes this. large amounts of users have accidentally locked up tokens and ether by losing their private keys. this is inefficient and provides a bad user experience. to accommodate new and inexperienced users, there needs to be a way to recover funds after the private key has been lost. sudo fixes this. finally, there are many tokens and ether sitting in smart contracts locked due to a bug. we could finally close eip issue #156. we cannot currently reclaim ether from stuck accounts. sudo fixes this. specification adds a new opcode (sudo) at 0xf8. sudo pops 8 parameters from the stack. besides the sender parameter, the parameters shall match call. gas: integer; maximum gas allowance for message call, safely using current gas counter if the counter is lower sender: address, truncated to lower 40 bytes; sets caller inside the call frame to: address, truncated to lower 40 bytes; sets address value: integer, raises exception amount specified is less than the value in sender account; transferred with call to recipient balance, sets callvalue instart: integer; beginning of memory to use for calldata insize: integer; length of memory to use for calldata outstart: integer; beginning of memory to replace with returndata outsize: integer; maximum returndata to place in memory following execution, sudo pushes a result value to the stack, indicating success or failure. if the call ended with stop, return, or selfdestruct, 1 is pushed. if the call ended with revert, invalid, or an evm assertion, 0 is pushed. rationale the gas parameter is first so that callers can tediously compute how much of their remaining gas to send at the last possible moment. the remaining parameters inherited from call are in the same order, with sender inserted between. security considerations it will be fine. copyright copyright and related rights waived via cc0. citation please cite this document as: william morriss (@wjmelements), baptiste vauthey (@thabaptiser), "eip-3455: sudo opcode [draft]," ethereum improvement proposals, no. 3455, april 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3455. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. the ethereum project: learning to dream with open minds | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search the ethereum project: learning to dream with open minds posted by mihai alisie on july 14, 2014 research & development “and those who were seen dancing were thought to be insane by those who could not hear the music.” friedrich nietzsche ethereum as a project is more than just a technology, even if technology is at its core. in the rush of creating, co-creating and debugging everything you sometimes lose sight of the bigger picture. you need stop for a second, take a step back and observe in order to fully appreciate what's going on. the project started as an idea in vitalik’s mind. ethereum, has now expanded into thousands and thousands of other minds around the world, thanks to this interconnected digital mesh called internet. a sea of minds brought together by the idea of a turing complete general purpose blockchain is creating, as you’re reading these lines, the minecraft of blockchain tech. in all this excitement we have had to think also, about how we can best ensure that the vision is not corrupted, while delivering the technology itself. this post is the first in a series that attempts to explain both the ethos and motivation behind the project as a whole. soulsearching: for profit or not? from inception, our intention was to deliver a technology aligned with the community at large and to encourage a meritocratic culture based on trust, openness and respect not only for our fellow ethereans but everyone united by raw passion for positive world change. over the past few months the model of our organization and the very nature of this project has been in discussion both amongst ourselves and between ourselves and the community. they were healthy discussions and i would like to personally thank everyone who cared enough to share their thoughts on our forums, in a blog comment or a reddit post. it has been an intense and interesting journey. along the way it made us reflect upon our values while looking at ourselves and asking what this project really means to each and all of us. during these long soul searching sessions we realized that most of the dichotomies boiled down to a single question: for profit or not? after researching a number of models and organizations, we arrived at the conclusion that in order to keep the protocol and the software as pure as possible the only real option was to build a non-profit structure with a declared mission to develop, maintain, nurture and explore the potential of this new technology. motivated not by money but radiant passion for this crazy idea of a free, open and decentralized world. that’s what make us happy in the end and most importantly what makes us get up and work on this project, proudly saying today we're building tomorrow. details regarding the non profit structure chosen will follow in a series of blogs. however this blog post is not about details, more about the bigger picture and why we’re doing it in the first place. continuing the experiment we all come from different backgrounds and life experiences, but in the end we're all connected through this meaningful project which enables us to explore our passions and ideas through code, art, hardware or sometimes something completely new. by design this project is breaking new ground in a way that has not been tried before. this by definition is a trial and error experiment, looking to continue the experiment started by bitcoin, on multiple levels. since this has never been tried before, there are no right or wrong answers or concrete experiences to fall back on. we are deep into uncharted territories. even if we do not yet grasp the full applications and implications, the sheer number of ideas and initiatives sparked by the core idea itself is encouraging, and gives us a glimpse at the limitless potential of our minds we are architecting and co-creating our own future "reality". i like to look at the ethereum project as a blank canvas, where anyone can create digital masterpieces. the technology behind it serving as a catalyst, enabling people to unfold their innate playful creativity. if the network and blockchain were to be the canvas, then the paints and colors would be the lines of code running transparently and censorlessly on top. everyone is invited to cocreate. the genesis sale represents the next step in this epic journey that lies ahead, and a way to bootstrap the ethereum ecosystem. the collective intelligence of the swarm will then have its collective fingertips at an amazing open technology, capable of unleashing waves of innovation across the web, and etherweb. with a technology like this available, centralized, corrupted monopolies that siphon from the blood and tears of humanity face rapid obsoletion. portal into greatness "don't ask yourself what the world needs. ask yourself what makes you come alive and then go do that. because what the world needs is people who have come alive." howard thurman most of us are aware that the current planetary operating system is pushing us into extinction as a species. finance seems to be the current paradigm humanity has to transcend on its path from a civilization type zero into a civilization type one. when a technology like ethereum exists, i feel like we almost have a debt to ourselves and our fellow species to explore its potential in the search of solutions. we truly have at our fingertips the power to craft the future we desire through code and purposeful action if you see something you don’t like, contribute with something you do like. we believe it is important, especially at this critical point in time, to follow our heart instead of meaningless extrinsic rewards. this is how, perhaps, we can open a portal toward our maximum potential, both on an individual and collective level. i suspect that sir timothy berners-lee was most likely unable to envision something like bitcoin running on top of his hyper text unified network protocol back in early 90’s. just as we are unable at this point to fully grasp the implications of the ongoing crypto renaissance running across the ubiquitous digital mesh that connects more than 2 billion minds. how far can we take it? what's the limit? is there really a limit in the first place? from our humble beginnings as foragers and hunters, we have arrived at a point where we are able to contemplate the nature of infinity. able to grasp the idea that we’re made from trillions of atoms vibrating in unison on a pale blue dot, all this while permanently connected through a digital planetary consciousness grid. we are learning to dream with open minds, just as we are dreaming with closed eyes. we are on the cusp of changing the world with our minds through lines of code dancing with atoms at the edge of singularity. the interesting part is just about to begin. how many rivers will we have to cross before we'll find our way? previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-2645: hierarchical deterministic wallet for layer-2 ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2645: hierarchical deterministic wallet for layer-2 authors tom brand , louis guthmann created 2020-05-13 discussion link https://ethereum-magicians.org/t/hierarchical-deterministic-wallet-for-computation-integrity-proof-cip-layer-2/4286 table of contents simple summary abstract motivation specification rationale backwards compatibility security considerations copyright simple summary in the context of computation integrity proof (cip) layer-2 solutions such as zk-rollups, users are required to sign messages on new elliptic curves optimized for those environnements. we leverage existing work on key derivation (bip32, bip39 and bip44) to define an efficient way to securely produce cip l2s private keys, as well as creating domain separation between layer-2 applications. abstract we provide a derivation path allowing a user to derive hierarchical keys for layer-2 solutions depending on the zk-technology, the application, the user’s layer-1 address, as well as an efficient grinding method to enforce the private key distribution within the curve domain. the propose derivation path is defined as follow m / purpose' / layer' / application' / eth_address_1' / eth_address_2' / index motivation in the context of computation integrity proof (cip) layer-2 solutions such as zk-rollups, users are required to sign messages on new elliptic curves optimized for those environments. extensive work has been done to make it secure on bitcoin via bip32, bip39 and bip44. these protocols are the standard for wallets in the entire industry, independent of the underlying blockchain. as layer-2 solutions are taking off, it is a necessary requirement to maintain the same standard and security in this new space. specification starkware keys are derived with the following bip43-compatible derivation path, with direct inspiration from bip44: m / purpose' / layer' / application' / eth_address_1' / eth_address_2' / index where: m the seed. purpose 2645 (the number of this eip). layer the 31 lowest bits of sha256 on the layer name. serve as a domain separator between different technologies. in the context of starkex, the value would be 579218131. application the 31 lowest bits of sha256 of the application name. serve as a domain separator between different applications. in the context of deversifi in june 2020, it is the 31 lowest bits of sha256(starkexdvf) and the value would be 1393043894. eth_address_1 / eth_address_2 the first and second 31 lowest bits of the corresponding eth_address. index to allow multiple keys per eth_address. as example, the expected path for address 0x0000….0000 assuming seed m and index 0 in the context of deversifi in june 2020: m/2645'/579218131'/1393043894'/0'/0'/0 the key derivation should follow the following algorithm n = 2**256 n = layer2 curve order path = stark derivation path bip32() = official bip-0032 derivation function on secp256k1 hash = sha256 i = 0 root_key = bip32(path) while true: key = hash(root_key|i) if (key < (n (n % n))): return key % n i++ this algorithm has been defined to maintain efficiency on existing restricted devices. nota bene: at each round, the probability for a key to be greater than (n (n % n)) is < 2^(-5). rationale this eip specifies two aspects of keys derivation in the context of hierarchical wallets: derivation path grinding algorithm to enforce a uniform distribution over the elliptic curve. the derivation path is defined to allow efficient keys separation based on technology and application while maintaining a 1-1 relation with the layer-1 wallet. in such a way, losing eip-2645 wallets falls back to losing the layer-1 wallet. backwards compatibility this standard complies with bip43. security considerations this eip has been defined to maintain separation of keys while providing foolproof logic on key derivation. copyright copyright and related rights waived via cc0. citation please cite this document as: tom brand , louis guthmann , "erc-2645: hierarchical deterministic wallet for layer-2 [draft]," ethereum improvement proposals, no. 2645, may 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2645. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1352: specify restricted address range for precompiles/system contracts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1352: specify restricted address range for precompiles/system contracts authors alex beregszaszi (@axic) created 2018-07-27 discussion link https://ethereum-magicians.org/t/eip-1352-specify-restricted-address-range-for-precompiles-system-contracts/1151 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary specify an ethereum address range occupied by precompiles and future system contracts. regular accounts and contracts cannot obtain such an address. abstract the address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts. motivation this will simplify certain future features where unless this is implemented, several exceptions must be specified. specification the address range between 0x0000000000000000000000000000000000000000 and 0x000000000000000000000000000000000000ffff is reserved for precompiles and system contracts. due to the extremely low probability (and lack of adequate testing possibilities) no explicit checks should be added to ensure that external transaction signing or the invoking of the create instruction can result in a precompile address. rationale n/a backwards compatibility no contracts on the main network have been created at the specified addresses. as a result it should pose no backwards compatibility problems. test cases n/a implementation n/a copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), "eip-1352: specify restricted address range for precompiles/system contracts [draft]," ethereum improvement proposals, no. 1352, july 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1352. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-211: new opcodes: returndatasize and returndatacopy ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-211: new opcodes: returndatasize and returndatacopy authors christian reitwiessner created 2017-02-13 table of contents simple summary abstract motivation specification rationale backwards compatibility test cases implementation copyright simple summary a mechanism to allow returning arbitrary-length data inside the evm has been requested for quite a while now. existing proposals always had very intricate problems associated with charging gas. this proposal solves the same problem while at the same time, it has a very simple gas charging mechanism and requires minimal changes to the call opcodes. its workings are very similar to the way calldata is handled already; after a call, return data is kept inside a virtual buffer from which the caller can copy it (or parts thereof) into memory. at the next call, the buffer is overwritten. this mechanism is 100% backwards compatible. abstract please see summary. motivation in some situations, it is vital for a function to be able to return data whose length cannot be anticipated before the call. in principle, this can be solved without alterations to the evm, for example by splitting the call into two calls where the first is used to compute only the size. all of these mechanisms, though, are very expensive in at least some situations. a very useful example of such a worst-case situation is a generic forwarding contract; a contract that takes call data, potentially makes some checks and then forwards it as is to another contract. the return data should of course be transferred in a similar way to the original caller. since the contract is generic and does not know about the contract it calls, there is no way to determine the size of the output without adapting the called contract accordingly or trying a logarithmic number of calls. compiler implementors are advised to reserve a zero-length area for return data if the size of the return data is unknown before the call and then use returndatacopy in conjunction with returndatasize to actually retrieve the data. note that this proposal also makes the eip that proposes to allow to return data in case of an intentional state reversion (eip-140) much more useful. since the size of the failure data might be larger than the regular return data (or even unknown), it is possible to retrieve the failure data after the call opcode has signalled a failure, even if the regular output area is not large enough to hold the data. specification if block.number >= byzantium_fork_blknum, add two new opcodes and amend the semantics of any opcode that creates a new call frame (like call, create, delegatecall, …) called call-like opcodes in the following. it is assumed that the evm (to be more specific: an evm call frame) has a new internal buffer of variable size, called the return data buffer. this buffer is created empty for each new call frame. upon executing any call-like opcode, the buffer is cleared (its size is set to zero). after executing a call-like opcode, the complete return data (or failure data, see eip-140) of the call is stored in the return data buffer (of the caller), and its size changed accordingly. as an exception, create and create2 are considered to return the empty buffer in the success case and the failure data in the failure case. if the call-like opcode is executed but does not really instantiate a call frame (for example due to insufficient funds for a value transfer or if the called contract does not exist), the return data buffer is empty. as an optimization, it is possible to share the return data buffer across call frames because at most one will be non-empty at any time. returndatasize: 0x3d pushes the size of the return data buffer onto the stack. gas costs: 2 (same as calldatasize) returndatacopy: 0x3e this opcode has similar semantics to calldatacopy, but instead of copying data from the call data, it copies data from the return data buffer. furthermore, accessing the return data buffer beyond its size results in a failure; i.e. if start + length overflows or results in a value larger than returndatasize, the current call stops in an out-of-gas condition. in particular, reading 0 bytes from the end of the buffer will read 0 bytes; reading 0 bytes from one-byte out of the buffer causes an exception. gas costs: 3 + 3 * ceil(amount / 32) (same as calldatacopy) rationale other solutions that would allow returning dynamic data were considered, but they all had to deduct the gas from the call opcode and thus were both complicated to implement and specify (5/8). since this proposal is very similar to the way calldata is handled, it fits nicely into the concept. furthermore, the ewasm architecture already handles return data in exactly the same way. note that the evm implementation needs to keep the return data until the next call or the return from the current call. since this resource was already paid for as part of the memory of the callee, it should not be a problem. implementations may either choose to keep the full memory of the callee alive until the next call or copy only the return data to a special memory area. keeping the memory of the callee until the next call-like opcode does not increase the peak memory usage in the following sense; any memory allocation in the caller’s frame that happens after the return from the call can be moved before the call without a change in gas costs, but will add this allocation to the peak allocation. the number values of the opcodes were allocated in the same nibble block that also contains calldatasize and calldatacopy. backwards compatibility this proposal introduces two new opcodes and stays fully backwards compatible apart from that. test cases implementation copyright copyright and related rights waived via cc0. citation please cite this document as: christian reitwiessner , "eip-211: new opcodes: returndatasize and returndatacopy," ethereum improvement proposals, no. 211, february 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-211. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. conference, alpha testnet and ether pre-sale updates | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search conference, alpha testnet and ether pre-sale updates posted by vitalik buterin on january 29, 2014 research & development important notice: any information from this post regarding the ether sale is highly outdated and probably inaccurate. please only consult the latest blog posts and official materials at ethereum.org for information on the sale ethereum received an incredible response at the miami bitcoin conference. we traveled there anticipating many technical questions as well as a philosophical discussion about the purpose of ethereum; however, the overwhelming amount of interest and enthusiasm for the project was much larger than we had anticipated. vitalik’s presentation was met with both a standing ovation and a question queue that took hours to address. because we intend on providing an equal opportunity to all those who want to be involved, and are reviewing the relevant logistical and regulatory issues for a token sale of this scale, we have decided to postpone the feb 1 launch of the sale. we will make the announcement of the new sale launch date on our official website: ethereum.org. the ethereum project is also excited to announce the alpha release of the open source testnet client to the community at the beginning of february. this will give people an opportunity to get involved with the project and experiment with ethereum scripts and contracts, and gain a better understanding of the technical properties of the ethereum platform. launching the testnet at this date will give those interested in the fundraiser a chance to better understand what the ethereum project is about before participating. the testnet will include full support for sending and receiving transactions, the initial version of the scripting language as described in our whitepaper, and may or may not include mining. this will also be the first major cryptocurrency project to have two official clients released at the same time, with one written in c++ and the other in go; a python client is also in the works. a compiler from the ethereum cll to ethereum script will be released very soon. a note on security the ether sale will not be launching on february 1st and any attempt to collect funds at this time should be considered a scam. there have been some scams in the forums thus please use caution and only consider information posted on ethereum.org to be legitimate. it is important to reinforce to all that only information released and posted at ethereum.org should be trusted as many are likely to impersonate us. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-6268: untransferability indicator for eip-1155 ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-6268: untransferability indicator for eip-1155 an extension of eip-1155 for indicating the transferability of the token. authors yuki aoki (@yuki-js) created 2022-01-06 discussion link https://ethereum-magicians.org/t/sbt-implemented-in-erc1155/12182 requires eip-165, eip-1155 table of contents abstract motivation specification rationale backwards compatibility security considerations copyright abstract this eip standardizes an interface indicating eip-1155-compatible token non-transferability using eip-165 feature detection. motivation soulbound tokens (sbt) are non-transferable tokens. while eip-5192 standardizes non-fungible sbts, a standard for soulbound semi-fungible or fungible tokens does not yet exist. the introduction of a standard non-transferability indicator that is agnostic to fungibility promotes the usage of souldbound semi-fungible or fungible tokens. 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. smart contracts implementing this standard must comform to the eip-1155 specification. smart contracts implementing this standard must implement all of the functions in the ierc6268 interface. smart contracts implementing this standard must implement the eip-165 supportsinterface function and must return the constant value true if 0xd87116f3 is passed through the interfaceid argument. for the token identifier _id that is marked as locked, locked(_id) must return the constant value true and any functions that try transferring the token, including safetransferfrom and safebatchtransferfrom function must throw. // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; interface ierc6268 { /// @notice either `lockedsingle` or `lockedbatch` must emit when the locking status is changed to locked. /// @dev if a token is minted and the status is locked, this event should be emitted. /// @param _id the identifier for a token. event lockedsingle(uint256 _id); /// @notice either `lockedsingle` or `lockedbatch` must emit when the locking status is changed to locked. /// @dev if a token is minted and the status is locked, this event should be emitted. /// @param _ids the list of identifiers for tokens. event lockedbatch(uint256[] _ids); /// @notice either `unlockedsingle` or `unlockedbatch` must emit when the locking status is changed to unlocked. /// @dev if a token is minted and the status is unlocked, this event should be emitted. /// @param _id the identifier for a token. event unlockedsingle(uint256 _id); /// @notice either `unlockedsingle` or `unlockedbatch` must emit when the locking status is changed to unlocked. /// @dev if a token is minted and the status is unlocked, this event should be emitted. /// @param _ids the list of identifiers for tokens. event unlockedbatch(uint256[] _ids); /// @notice returns the locking status of the token. /// @dev sbts assigned to zero address are considered invalid, and queries /// about them do throw. /// @param _id the identifier for a token. function locked(uint256 _id) external view returns (bool); /// @notice returns the locking statuses of the multiple tokens. /// @dev sbts assigned to zero address are considered invalid, and queries /// about them do throw. /// @param _ids the list of identifiers for tokens function lockedbatch(uint256[] _ids) external view returns (bool); } rationale needs discussion. backwards compatibility this proposal is fully backward compatible with eip-1155. security considerations needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: yuki aoki (@yuki-js), "erc-6268: untransferability indicator for eip-1155 [draft]," ethereum improvement proposals, no. 6268, january 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6268. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1014: skinny create2 ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-1014: skinny create2 authors vitalik buterin (@vbuterin) created 2018-04-20 table of contents specification motivation rationale clarifications examples specification adds a new opcode (create2) at 0xf5, which takes 4 stack arguments: endowment, memory_start, memory_length, salt. behaves identically to create (0xf0), except using keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] instead of the usual sender-and-nonce-hash as the address where the contract is initialized at. the create2 has the same gas schema as create, but also an extra hashcost of gsha3word * ceil(len(init_code) / 32), to account for the hashing that must be performed. the hashcost is deducted at the same time as memory-expansion gas and creategas is deducted: before evaluation of the resulting address and the execution of init_code. 0xff is a single byte, address is always 20 bytes, salt is always 32 bytes (a stack item). the preimage for the final hashing round is thus always exactly 85 bytes long. the coredev-call at 2018-08-10 decided to use the formula above. motivation allows interactions to (actually or counterfactually in channels) be made with addresses that do not exist yet on-chain but can be relied on to only possibly eventually contain code that has been created by a particular piece of init code. important for state-channel use cases that involve counterfactual interactions with contracts. rationale address formula ensures that addresses created with this scheme cannot collide with addresses created using the traditional keccak256(rlp([sender, nonce])) formula, as 0xff can only be a starting byte for rlp for data many petabytes long. ensures that the hash preimage has a fixed size, gas cost since address calculation depends on hashing the init_code, it would leave clients open to dos attacks if executions could repeatedly cause hashing of large pieces of init_code, since expansion of memory is paid for only once. this eip uses the same cost-per-word as the sha3 opcode. clarifications the init_code is the code that, when executed, produces the runtime bytecode that will be placed into the state, and which typically is used by high level languages to implement a ‘constructor’. this eip makes collisions possible. the behaviour at collisions is specified by eip-684: if a contract creation is attempted, due to either a creation transaction or the create (or future create2) opcode, and the destination address already has either nonzero nonce, or nonempty code, then the creation throws immediately, with exactly the same behavior as would arise if the first byte in the init code were an invalid opcode. this applies retroactively starting from genesis. specifically, if nonce or code is nonzero, then the create-operation fails. with eip-161 account creation transactions and the create operation shall, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one this means that if a contract is created in a transaction, the nonce is immediately non-zero, with the side-effect that a collision within the same transaction will always fail – even if it’s carried out from the init_code itself. it should also be noted that selfdestruct (0xff) has no immediate effect on nonce or code, thus a contract cannot be destroyed and recreated within one transaction. examples example 0 address 0x0000000000000000000000000000000000000000 salt 0x0000000000000000000000000000000000000000000000000000000000000000 init_code 0x00 gas (assuming no mem expansion): 32006 result: 0x4d1a2e2bb4f88f0250f26ffff098b0b30b26bf38 example 1 address 0xdeadbeef00000000000000000000000000000000 salt 0x0000000000000000000000000000000000000000000000000000000000000000 init_code 0x00 gas (assuming no mem expansion): 32006 result: 0xb928f69bb1d91cd65274e3c79d8986362984fda3 example 2 address 0xdeadbeef00000000000000000000000000000000 salt 0x000000000000000000000000feed000000000000000000000000000000000000 init_code 0x00 gas (assuming no mem expansion): 32006 result: 0xd04116cdd17bebe565eb2422f2497e06cc1c9833 example 3 address 0x0000000000000000000000000000000000000000 salt 0x0000000000000000000000000000000000000000000000000000000000000000 init_code 0xdeadbeef gas (assuming no mem expansion): 32006 result: 0x70f2b2914a2a4b783faefb75f459a580616fcb5e example 4 address 0x00000000000000000000000000000000deadbeef salt 0x00000000000000000000000000000000000000000000000000000000cafebabe init_code 0xdeadbeef gas (assuming no mem expansion): 32006 result: 0x60f3f640a8508fc6a86d45df051962668e1e8ac7 example 5 address 0x00000000000000000000000000000000deadbeef salt 0x00000000000000000000000000000000000000000000000000000000cafebabe init_code 0xdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeefdeadbeef gas (assuming no mem expansion): 32012 result: 0x1d8bfdc5d46dc4f61d6b6115972536ebe6a8854c example 6 address 0x0000000000000000000000000000000000000000 salt 0x0000000000000000000000000000000000000000000000000000000000000000 init_code 0x gas (assuming no mem expansion): 32000 result: 0xe33c0c7f7df4809055c3eba6c09cfe4baf1bd9e0 citation please cite this document as: vitalik buterin (@vbuterin), "eip-1014: skinny create2," ethereum improvement proposals, no. 1014, april 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1014. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2159: common prometheus metrics names for clients ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: interface eip-2159: common prometheus metrics names for clients authors adrian sutton (@ajsutton) created 2019-07-01 table of contents simple summary abstract motivation specification rationale backwards compatibility implementation references copyright simple summary standardized names of common metrics for ethereum clients to use with prometheus, a widely used monitoring and alerting solution. abstract many ethereum clients expose a range of metrics in a format compatible with prometheus to allow operators to monitor the client’s behaviour and performance and raise alerts if the chain isn’t progressing or there are other indications of errors. while the majority of these metrics are highly client-specific, reporting on internal implementation details of the client, some are applicable to all clients. by standardizing the naming and format of these common metrics, operators are able to monitor the operation of multiple clients in a single dashboard or alerting configuration. motivation using common names and meanings for metrics which apply to all clients allows node operators to monitor clusters of nodes using heterogeneous clients using a single dashboard and alerting configuration. currently there are no agreed names or meanings, leaving client developers to invent their own making it difficult to monitor a heterogeneous cluster. specification the table below defines metrics which may be captured by ethereum clients which expose metrics to prometheus. clients may expose additional metrics however these should not use the ethereum_ prefix. name metric type definition json-rpc equivalent ethereum_blockchain_height gauge the current height of the canonical chain eth_blocknumber ethereum_best_known_block_number gauge the estimated highest block available highestblock of eth_syncing or eth_blocknumber if not syncing ethereum_peer_count gauge the current number of peers connected net_peercount ethereum_peer_limit gauge the maximum number of peers this node allows to connect no equivalent note that ethereum_best_known_block_number always has a value. when the eth_syncing json-rpc method would return false, the current chain height is used. rationale the defined metrics are independent of ethereum client implementation but provide sufficient information to create an overview dashboard to support monitoring a group of ethereum nodes. there is a similar, though more prescriptive, specification for beacon chain client metrics. the specific details of how to expose the metrics has been omitted as there is variance in existing implementations and standardising this does not provide any significant benefit. backwards compatibility this is not a consensus affecting change. clients may already be publishing these metrics using different names and changing to the new form may break existing alerts or dashboards. clients that want to avoid this incompatibility can expose the metrics under both the old and new names. clients may also be publishing metrics with a different meaning using these names. backwards compatibility cannot be preserved in this case. implementation pantheon switched to using these standard metric names in its 1.2 release: https://github.com/pegasyseng/pantheon/pull/1634. references prometheus. https://prometheus.io beacon chain metrics specification. https://github.com/ethereum/eth2.0-metrics/blob/master/metrics.md copyright copyright and related rights waived via cc0. citation please cite this document as: adrian sutton (@ajsutton), "eip-2159: common prometheus metrics names for clients," ethereum improvement proposals, no. 2159, july 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2159. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. on bitcoin maximalism, and currency and platform network effects | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search on bitcoin maximalism, and currency and platform network effects posted by vitalik buterin on november 20, 2014 research & development one of the latest ideas that has come to recently achieve some prominence in parts of the bitcoin community is the line of thinking that has been described by both myself and others as "bitcoin dominance maximalism" or just "bitcoin maximalism" for short essentially, the idea that an environment of multiple competing cryptocurrencies is undesirable, that it is wrong to launch "yet another coin", and that it is both righteous and inevitable that the bitcoin currency comes to take a monopoly position in the cryptocurrency scene. note that this is distinct from a simple desire to support bitcoin and make it better; such motivations are unquestionably beneficial and i personally continue to contribute to bitcoin regularly via my python library pybitcointools. rather, it is a stance that building something on bitcoin is the only correct way to do things, and that doing anything else is unethical (see this post for a rather hostile example). bitcoin maximalists often use "network effects" as an argument, and claim that it is futile to fight against them. however, is this ideology actually such a good thing for the cryptocurrency community? and is its core claim, that network effects are a powerful force strongly favoring the eventual dominance of already established currencies, really correct, and even if it is, does that argument actually lead where its adherents think it leads? the technicals first, an introduction to the technical strategies at hand. in general, there are three approaches to creating a new crypto protocol: build on bitcoin the blockchain, but not bitcoin the currency (metacoins, eg. most features of counterparty) build on bitcoin the currency, but not bitcoin the blockchain (sidechains) create a completely standalone platform meta-protocols are relatively simple to describe: they are protocols that assign a secondary meaning to certain kinds of specially formatted bitcoin transactions, and the current state of the meta-protocol can be determined by scanning the blockchain for valid metacoin transactions and sequentially processing the valid ones. the earliest meta-protocol to exist was mastercoin; counterparty is a newer one. meta-protocols make it much quicker to develop a new protocol, and allow protocols to benefit directly from bitcoin's blockchain security, although at a high cost: meta-protocols are not compatible with light client protocols, so the only efficient way to use a meta-protocol is via a trusted intermediary. sidechains are somewhat more complicated. the core underlying idea revolves around a "two-way-pegging" mechanism, where a "parent chain" (usually bitcoin) and a "sidechain" share a common currency by making a unit of one convertible into a unit of the other. the way it works is as follows. first, in order to get a unit of side-coin, a user must send a unit of parent-coin into a special "lockbox script", and then submit a cryptographic proof that this transaction took place into the sidechain. once this transaction confirms, the user has the side-coin, and can send it at will. when any user holding a unit of side-coin wants to convert it back into parent-coin, they simply need to destroy the side-coin, and then submit a proof that this transaction took place to a lockbox script on the main chain. the lockbox script would then verify the proof, and if everything checks out it would unlock the parent-coin for the submitter of the side-coin-destroying transaction to spend. unfortunately, it is not practical to use the bitcoin blockchain and currency at the same time; the basic technical reason is that nearly all interesting metacoins involve moving coins under more complex conditions than what the bitcoin protocol itself supports, and so a separate "coin" is required (eg. msc in mastercoin, xcp in counterparty). as we will see, each of these approaches has its own benefits, but it also has its own flaws. this point is important; particularly, note that many bitcoin maximalists' recent glee at counterparty forking ethereum was misplaced, as counterparty-based ethereum smart contracts cannot manipulate btc currency units, and the asset that they are instead likely to promote (and indeed already have promoted) is the xcp. network effects now, let us get to the primary argument at play here: network effects. in general, network effects can be defined simply: a network effect is a property of a system that makes the system intrinsically more valuable the more people use it. for example, a language has a strong network effect: esperanto, even if it is technically superior to english in the abstract, is less useful in practice because the whole point of a language is to communicate with other people and not many other people speak esperanto. on the other hand, a single road has a negative network effect: the more people use it the more congested it becomes. in order to properly understand what network effects are at play in the cryptoeconomic context, we need to understand exactly what these network effects are, and exactly what thing each effect is attached to. thus, to start off, let us list a few of the major ones (see here and here for primary sources): security effect: systems that are more widely adopted derive their consensus from larger consensus groups, making them more difficult to attack. payment system network effect: payment systems that are accepted by more merchants are more attractive to consumers, and payment systems used by more consumers are more attractive to merchants. developer network effect: there are more people interested in writing tools that work with platforms that are widely adopted, and the greater number of these tools will make the platform easier to use. integration network effect: third party platforms will be more willing to integrate with a platform that is widely adopted, and the greater number of these tools will make the platform easier to use. size stability effect: currencies with larger market cap tend to be more stable, and more established cryptocurrencies are seen as more likely (and therefore by self-fulfilling-prophecy actually are more likely) to remain at nonzero value far into the future. unit of account network effect: currencies that are very prominent, and stable, are used as a unit of account for pricing goods and services, and it is cognitively easier to keep track of one's funds in the same unit that prices are measured in. market depth effect: larger currencies have higher market depth on exchanges, allowing users to convert larger quantities of funds in and out of that currency without taking a hit on the market price. market spread effect: larger currencies have higher liquidity (ie. lower spread) on exchanges, allowing users to convert back and forth more efficiently. intrapersonal single-currency preference effect: users that already use a currency for one purpose prefer to use it for other purposes both due to lower cognitive costs and because they can maintain a lower total liquid balance among all cryptocurrencies without paying interchange fees. interpersonal single-currency preference effect: users prefer to use the same currency that others are using to avoid interchange fees when making ordinary transactions marketing network effect: things that are used by more people are more prominent and thus more likely to be seen by new users. additionally, users have more knowledge about more prominent systems and thus are less concerned that they might be exploited by unscrupulous parties selling them something harmful that they do not understand. regulatory legitimacy network effect: regulators are less likely to attack something if it is prominent because they will get more people angry by doing so the first thing that we see is that these network effects are actually rather neatly split up into several categories: blockchain-specific network effects (1), platform-specific network effects (2-4), currency-specific network effects (5-10), and general network effects (11-12), which are to a large extent public goods across the entire cryptocurrency industry. there is a substantial opportunity for confusion here, since bitcoin is simultaneously a blockchain, a currency and a platform, but it is important to make a sharp distinction between the three. the best way to delineate the difference is as follows: a currency is something which is used as a medium of exchange or store of value; for example, dollars, btc and doge. a platform is a set of interoperating tools and infrastructure that can be used to perform certain tasks; for currencies, the basic kind of platform is the collection of a payment network and the tools needed to send and receive transactions in that network, but other kinds of platforms may also emerge. a blockchain is a consensus-driven distributed database that modifies itself based on the content of valid transactions according to a set of specified rules; for example, the bitcoin blockchain, the litecoin blockchain, etc. to see how currencies and platforms are completely separate, the best example to use is the world of fiat currencies. credit cards, for example, are a highly multi-currency platform. someone with a credit card from canada tied to a bank account using canadian dollars can spend funds at a merchant in switzerland accepting swiss francs, and both sides barely know the difference. meanwhile, even though both are (or at least can be) based on the us dollar, cash and paypal are completely different platforms; a merchant accepting only cash will have a hard time with a customer who only has a paypal account. as for how platforms and blockchains are separate, the best example is the bitcoin payment protocol and proof of existence. although the two use the same blockchain, they are completely different applications, users of one have no idea how to interpret transactions associated with the other, and it is relatively easy to see how they benefit from completely different network effects so that one can easily catch on without the other. note that protocols like proof of existence and factom are mostly exempt from this discussion; their purpose is to embed hashes into the most secure available ledger, and while a better ledger has not materialized they should certainly use bitcoin, particularly because they can use merkle trees to compress a large number of proofs into a single hash in a single transaction. network effects and metacoins now, in this model, let us examine metacoins and sidechains separately. with metacoins, the situation is simple: metacoins are built on bitcoin the blockchain, and not bitcoin the platform or bitcoin the currency. to see the former, note that users need to download a whole new set of software packages in order to be able to process bitcoin transactions. there is a slight cognitive network effect from being able to use the same old infrastructure of bitcoin private/public key pairs and addresses, but this is a network effect for the combination of ecdsa, sha256+ripemd160 and base 58 and more generally the whole concept of cryptocurrency, not the bitcoin platform; dogecoin inherits exactly the same gains. to see the latter, note that, as mentioned above, counterparty has its own internal currency, the xcp. hence, metacoins benefit from the network effect of bitcoin's blockchain security, but do not automatically inherit all of the platform-specific and currency-specific network effects. of course, metacoins' departure from the bitcoin platform and bitcoin currency is not absolute. first of all, even though counterparty is not "on" the bitcoin platform, it can in a very meaningful sense be said to be "close" to the bitcoin platform one can exchange back and forth between btc and xcp very cheaply and efficiently. cross-chain centralized or decentralized exchange, while possible, is several times slower and more costly. second, some features of counterparty, particularly the token sale functionality, do not rely on moving currency units under any conditions that the bitcoin protocol does not support, and so one can use that functionality without ever purchasing xcp, using btc directly. finally, transaction fees in all metacoins can be paid in btc, so in the case of purely non-financial applications metacoins actually do fully benefit from bitcoin's currency effect, although we should note that in most non-financial cases developers are used to messaging being free, so convincing anyone to use a non-financial blockchain dapp at $0.05 per transaction will likely be an uphill battle. in some of these applications particularly, perhaps to bitcoin maximalists' chagrin, counterparty's crypto 2.0 token sales, the desire to move back and forth quickly to and from bitcoin, as well as the ability to use it directly, may indeed create a platform network effect that overcomes the loss of secure light client capability and potential for blockchain speed and scalability upgrades, and it is in these cases that metacoins may find their market niche. however, metacoins are most certainly not an all-purpose solution; it is absurd to believe that bitcoin full nodes will have the computational ability to process every single crypto transaction that anyone will ever want to do, and so eventually movement to either scalable architectures or multichain environments will be necessary. network effects and sidechains sidechains have the opposite properties of metacoins. they are built on bitcoin the currency, and thus benefit from bitcoin's currency network effects, but they are otherwise exactly identical to fully independent chains and have the same properties. this has several pros and cons. on the positive side, it means that, although "sidechains" by themselves are not a scalability solution as they do not solve the security problem, future advancements in multichain, sharding or other scalability strategies are all open to them to adopt. on the negative side, however, they do not benefit from bitcoin's platform network effects. one must download special software in order to be able to interact with a sidechain, and one must explicitly move one's bitcoins onto a sidechain in order to be able to use it a process wich is equally as difficult as converting them into a new currency in a new network via a decentralized exchange. in fact, blockstream employees have themselves admitted that the process for converting side-coins back into bitcoins is relatively inefficient, to the point that most people seeking to move their bitcoins there and back will in fact use exactly the same centralized or decentralized exchange processes as would be used to migrate to a different currency on an independent blockchain. additionally, note that there is one security approach that independent networks can use which is not open to sidechains: proof of stake. the reasons for this are twofold. first one of the key arguments in favor of proof of stake is that even a successful attack against proof of stake will be costly for the attacker, as the attacker will need to keep his currency units deposited and watch their value drop drastically as the market realizes that the coin is compromised. this incentive effect does not exist if the only currency inside of a network is pegged to an external asset whose value is not so closely tied to that network's success. second, proof of stake gains much of its security because the process of buying up 50% of a coin in order to mount a takeover attack will itself increase the coin's price drastically, making the attack even more expensive for the attacker. in a proof of stake sidechain, however, one can easily move a very large quantity of coins into a chain from the parent chain, an mount the attack without moving the asset price at all. note that both of these arguments continue to apply even if bitcoin itself upgrades to proof of stake for its security. hence, if you believe that proof of stake is the future, then both metacoins and sidechains (or at least pure sidechains) become highly suspect, and thus for that purely technical reason bitcoin maximalism (or, for that matter, ether maximalism, or any other kind of currency maximalism) becomes dead in the water. currency network effects, revisited altogether, the conclusion from the above two points is twofold. first, there is no universal and scalable approach that allows users to benefit from bitcoin's platform network effects. any software solution that makes it easy for bitcoin users to move their funds to sidechains can be easily converted into a solution that makes it just as easy for bitcoin users to convert their funds into an independent currency on an independent chain. on the other hand, however, currency network effects are another story, and may indeed prove to be a genuine advantage for bitcoin-based sidechains over fully independent networks. so, what exactly are these effects and how powerful is each one in this context? let us go through them again: size-stability network effect (larger currencies are more stable) this network effect is legitimate, and bitcoin has been shown to be less volatile than smaller coins. unit of account network effect (very large currencies become units of account, leading to more purchasing power stability via price stickiness as well as higher salience) unfortunately, bitcoin will likely never be stable enough to trigger this effect; the best empirical evidence we can see for this is likely the valuation history of gold. market depth effect (larger currencies support larger transactions without slippage and have a lower bid/ask spread) these effect are legitimate up to a point, but then beyond that point (perhaps a market cap of $10-$100m), the market depth is imply good enough and the spread is low enough for nearly all types of transactions, and the benefit from further gains is small. single-currency preference effect (people prefer to deal with fewer currencies, and prefer to use the same currencies that others are using) the intrapersonal and interpersonal parts to this effect are legitimate, but we note that (i) the intrapersonal effect only applies within individual people, not between people, so it does not prevent an ecosystem with multiple preferred global currencies from existing, and (ii) the interpersonal effect is small as interchange fees especially in crypto tend to be very low, less than 0.30%, and will likely go down to essentially zero with decentralized exchange. hence, the single-currency preference effect is likely the largest concern, followed by the size stability effects, whereas the market depth effects are likely relatively tiny once a cryptocurrency gets to a substantial size. however, it is important to note that the above points have several major caveats. first, if (1) and (2) dominate, then we know of explicit strategies for making a new coin that is even more stable than bitcoin even at a smaller size; thus, they are certainly not points in bitcoin's favor. second, those same strategies (particularly the exogenous ones) can actually be used to create a stable coin that is pegged to a currency that has vastly larger network effects than even bitcoin itself; namely, the us dollar. the us dollar is thousands of times larger than bitcoin, people are already used to thinking in terms of it, and most importantly of all it actually maintains its purchasing power at a reasonable rate in the short to medium term without massive volatility. employees of blockstream, the company behind sidechains, have often promoted sidechains under the slogan "innovation without speculation"; however, the slogan ignores that bitcoin itself is quite speculative and as we see from the experience of gold always will be, so seeking to install bitcoin as the only cryptoasset essentially forces all users of cryptoeconomic protocols to participate in speculation. want true innovation without speculation? then perhaps we should all engage in a little us dollar stablecoin maximalism instead. finally, in the case of transaction fees specifically, the intrapersonal single-currency preference effect arguably disappears completely. the reason is that the quantities involved are so small ($0.01-$0.05 per transaction) that a dapp can simply siphon off $1 from a user's bitcoin wallet at a time as needed, not even telling the user that other currencies exist, thereby lowering the cognitive cost of managing even thousands of currencies to zero. the fact that this token exchange is completely non-urgent also means that the client can even serve as a market maket while moving coins from one chain to the other, perhaps even earning a profit on the currency interchange bid/ask spread. furthermore, because the user does not see gains and losses, and the user's average balance is so low that the central limit theorem guarantees with overwhelming probability that the spikes and drops will mostly cancel each other out, stability is also fairly irrelevant. hence, we can make the point that alternative tokens which are meant to serve primarily as "cryptofuels" do not suffer from currency-specific network effect deficiencies at all. let a thousand cryptofuels bloom. incentive and psychological arguments there is another class of argument, one which may perhaps be called a network effect but not completely, for why a service that uses bitcoin as a currency will perform better: the incentivized marketing of the bitcoin community. the argument goes as follows. services and platforms based on bitcoin the currency (and to a slight extent services based on bitcoin the platform) increase the value of bitcoin. hence, bitcoin holders would personally benefit from the value of their btc going up if the service gets adopted, and are thus motivated to support it. this effect occurs on two levels: the individual and the corporate. the corporate effect is a simple matter of incentives; large businesses will actually support or even create bitcoin-based dapps to increase bitcoin's value, simply because they are so large that even the portion of the benefit that personally accrues to themselves is enough to offset the costs; this is the "speculative philanthropy" strategy described by daniel krawisz. the individual effect is not so much directly incentive-based; each individual's ability to affect bitcoin's value is tiny. rather, it's more a clever exploitation of psychological biases. it's well-known that people tend to change their moral values to align with their personal interests, so the channel here is more complex: people who hold btc start to see it as being in the common interest for bitcoin to succeed, and so they will genuinely and excitedly support such applications. as it turns out, even a small amount of incentive suffices to shift over people's moral values to such a large extent, creating a psychological mechanism that manages to overcome not just the coordination problem but also, to a weak extent, the public goods problem. there are several major counterarguments to this claim. first, it is not at all clear that the total effect of the incentive and psychological mechanisms actually increases as the currency gets larger. although a larger size leads to more people affected by the incentive, a smaller size creates a more concentrated incentive, as people actually have the opportunity to make a substantial difference to the success of the project. the tribal psychology behind incentive-driven moral adjustment may well be stronger for small "tribes" where individuals also have strong social connections to each other than larger tribes where such connections are more diffuse; this is somewhat similar to the gemeinschaft vs gesellschaft distinction in sociology. perhaps a new protocol needs to have a concentrated set of highly incentivized stakeholders in order to seed a community, and bitcoin maximalists are wrong to try to knock this ladder down after bitcoin has so beautifully and successfully climbed up it. in any case, all of the research around optimum currency areas will have to be heavily redone in the context of the newer volatile cryptocurrencies, and the results may well go down either way. second, the ability for a network to issue units of a new coin has been proven to be a highly effective and successful mechanism for solving the public goods problem of funding protocol development, and any platform that does not somehow take advantage of the seignorage revenue from creating a new coin is at a substantial disadvantage. so far, the only major crypto 2.0 protocol-building company that has successfully funded itself without some kind of "pre-mine" or "pre-sale" is blockstream (the company behind sidechains), which recently received $21 million of venture capital funding from silicon valley investors. given blockstream's self-inflicted inability to monetize via tokens, we are left with three viable explanations for how investors justified the funding: the funding was essentially an act of speculative philathropy on the part of silicon valley venture capitalists looking to increase the value of their btc and their other btc-related investments. blockstream intends to earn revenue by taking a cut of the fees from their blockchains (non-viable because the public will almost certainly reject such a clear and blatant centralized siphoning of resources even more virulently then they would reject a new currency) blockstream intends to "sell services", ie. follow the redhat model (viable for them but few others; note that the total room in the market for redhat-style companies is quite small) both (1) and (3) are highly problematic; (3) because it means that few other companies will be able to follow its trail and because it gives them the incentive to cripple their protocols so they can provide centralized overlays, and (1) because it means that crypto 2.0 companies must all follow the model of sucking up to the particular concentrated wealthy elite in silicon valley (or maybe an alternative concentrated wealthy elite in china), hardly a healthy dynamic for a decentralized ecosystem that prides itself on its high degree of political independence and its disruptive nature. ironically enough, the only "independent" sidechain project that has so far announced itself, truthcoin, has actually managed to get the best of both worlds: the project got on the good side of the bitcoin maximalist bandwagon by announcing that it will be a sidechain, but in fact the development team intends to introduce into the platform two "coins" one of which will be a btc sidechain token and the other an independent currency that is meant to be, that's right, crowd-sold. a new strategy thus, we see that while currency network effects are sometimes moderately strong, and they will indeed exert a preference pressure in favor of bitcoin over other existing cryptocurrencies, the creation of an ecosystem that uses bitcoin exclusively is a highly suspect endeavor, and one that will lead to a total reduction and increased centralization of funding (as only the ultra-rich have sufficient concentrated incentive to be speculative philanthropists), closed doors in security (no more proof of stake), and is not even necessarily guaranteed to end with bitcoin willing. so is there an alternative strategy that we can take? are there ways to get the best of both worlds, simultaneously currency network effects and securing the benefits of new protocols launching their own coins? as it turns out, there is: the dual-currency model. the dual-currency model, arguably pioneered by robert sams, although in various incarnations independently discovered by bitshares, truthcoin and myself, is at the core simple: every network will contain two (or even more) currencies, splitting up the role of medium of transaction and vehicle of speculation and stake (the latter two roles are best merged, because as mentioned above proof of stake works best when participants suffer the most from a fork). the transactional currency will be either a bitcoin sidechain, as in truthcoin's model, or an endogenous stablecoin, or an exogenous stablecoin that benefits from the almighty currency network effect of the us dollar (or euro or cny or sdr or whatever else). hayekian currency competition will determine which kind of bitcoin, altcoin or stablecoin users prefer; perhaps sidechain technology can even be used to make one particular stablecoin transferable across many networks. the vol-coin will be the unit of measurement of consensus, and vol-coins will sometimes be absorbed to issue new stablecoins when stablecoins are consumed to pay transaction fees; hence, as explainted in the argument in the linked article on stablecoins, vol-coins can be valued as a percentage of future transaction fees. vol-coins can be crowd-sold, maintaining the benefits of a crowd sale as a funding mechanism. if we decide that explicit pre-mines or pre-sales are "unfair", or that they have bad incentives because the developers' gain is frontloaded, then we can instead use voting (as in dpos) or prediction markets instead to distribute coins to developers in a decentralized way over time. another point to keep in mind is, what happens to the vol-coins themselves? technological innovation is rapid, and if each network gets unseated within a few years, then the vol-coins may well never see substantial market cap. one answer is to solve the problem by using a clever combination of satoshian thinking and good old-fashioned recursive punishment systems from the offline world: establish a social norm that every new coin should pre-allocate 50-75% of its units to some reasonable subset of the coins that came before it that directly inspired its creation, and enforce the norm blockchain-style if your coin does not honor its ancestors, then its descendants will refuse to honor it, instead sharing the extra revenues between the originally cheated ancestors and themselves, and no one will fault them for that. this would allow vol-coins to maintain continuity over the generations. bitcoin itself can be included among the list of ancestors for any new coin. perhaps an industry-wide agreement of this sort is what is needed to promote the kind of cooperative and friendly evolutionary competition that is required for a multichain cryptoeconomy to be truly successful. would we have used a vol-coin/stable-coin model for ethereum had such strategies been well-known six months ago? quite possibly yes; unfortunately it's too late to make the decision now at the protocol level, particularly since the ether genesis block distribution and supply model is essentially finalized. fortunately, however, ethereum allows users to create their own currencies inside of contracts, so it is entirely possible that such a system can simply be grafted on, albeit slightly unnaturally, over time. even without such a change, ether itself will retain a strong and steady value as a cryptofuel, and as a store of value for ethereum-based security deposits, simply because of the combination of the ethereum blockchain's network effect (which actually is a platform network effect, as all contracts on the ethereum blockchain have a common interface and can trivially talk to each other) and the weak-currency-network-effect argument described for cryptofuels above preserves for it a stable position. for 2.0 multichain interaction, however, and for future platforms like truthcoin, the decision of which new coin model to take is all too relevant. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements security advisory [implementation bugs in go and python clients can cause dos – fixed – please update clients] | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search security advisory [implementation bugs in go and python clients can cause dos – fixed – please update clients] posted by jutta steiner on september 2, 2015 security state transition and consensus issue in geth client causes panic (crash) when processing a (valid) block with a specific combination of transactions, which may cause overall network instability if block is accepted and relayed by unaffected clients thus causing a dos. this may happen in a block that contains transactions which suicide to the block reward address. affected configurations: issue reported for geth.while investigating the issue, related issues were discovered and corrected in pyethereum, hence pyethapp is also affected. c++ clients are unaffected. likelihood: low severity: high complexity: high impact: network instability and dos details: a block containing a specific combination of transactions which include one or more suicide calls, while valid, causes panic crash in go-ethereum client and crash in pyethereum. additional details may be posted when available. effects on expected chain reorganisation depth: none. remedial action taken by ethereum: provision of fixes as below. proposed temporary workaround: switch to unaffected client such as eth (c++). fix:upgrade geth and pyethereum client software. go-ethereum (geth): please note that the current stable version of geth is now 1.1.1; if you are running 1.0 and using a package manager such as apt-get or homebrew the client will be upgraded. if using the ppa: sudo apt-get update then sudo apt-get upgrade if using brew: brew update then brew reinstall ethereum if using a windows binary: download the updated binary. if you are building from source: git pull followed by make geth (please use the master branch commit 8f09242d7f527972acb1a8b2a61c9f55000e955d) the correct version for this update on ubuntu and osx is geth/v1.1.1-8f09242d pyethereum: users of pyethapp should reinstall > pip install pyethapp --force-reinstall previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-3607: reject transactions from senders with deployed code ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-3607: reject transactions from senders with deployed code do not allow transactions for which `tx.sender` has any code deployed. authors dankrad feist (@dankrad), dmitry khovratovich (@khovratovich), marius van der wijden (@mariusvanderwijden) created 2021-06-10 table of contents abstract motivation generating address collisions background specification rationale backwards compatibility test cases reference implementation security considerations copyright abstract ethereum addresses are currently only 160 bits long. this means it is possible to create a collision between a contract account and an externally owned account (eoa) using an estimated 2**80 computing operations, which is feasible now given a large budget (ca. 10 billion usd). the fix in this eip prevents the worst possible attack, where a safe looking contract (e.g. a token wrapper or an amm-type contract) is deployed to attract user funds, which can then be spent using the eoa key for the same address. the fix is to never allow to use an address that already has code deployed as an eoa address. motivation generating address collisions by creating keys for 2**80 eoas and simulating the deployment of 2**80 contracts from these eoas (one each), one expects to find about one collision where an eoa has the same address as one contract. this very simple form of the attack requires the storage of 2**80 addresses, which is a practical barrier: it would require 2.4*10**25 bytes of memory (24 yottabyte). however, there are cycle finding algorithms that can perform the collision search without requiring large amounts of storage. an estimate for the complexity has been made here. we estimate that a collision between a contract and an eoa could be found in about one year with an investment of ca. us$10 billion in hardware and electricity. background there is currently a discussion to move to 256-bit addresses on ethereum, which would increase collision resistance to a complexity of 2**128 which is currently thought infeasible for the foreseeable future. however, with 160 bit addresses, the collision problem can be effectively solved now, as demonstrated above. most attacks that can occur via address collisions are quite impractical: they involve users sending funds to an address before a contract is deployed. this is a very rare application in practice and users can easily circumvent the attack by never sending funds to a contract until it has been safely deployed with enough confirmations. however, the yellow paper does not explicitly specify how a client should handle the case where a transaction is sent from an account that already has contract code deployed; presumably because this was considered infeasible at the time. the assumption is that most client would allow this transaction in their current state. this eip is to specify this behaviour to always forbid such transactions. this fixes most realistic or serious attacks due to address collisions. specification any transaction where tx.sender has a codehash != emptycodehash must be rejected as invalid, where emptycodehash = 0xc5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470. the invalid transaction must be rejected by the client and not be included in a block. a block containing such a transaction must be considered invalid. rationale we note that it was always the expected that a contract account’s behaviour is constrained by the code in that contract – which means that the account’s funds should not suddenly be spendable by some private key. it was just implicitly assumed in the past that a 160 bit address length is enough to provide collision resistance, and thus that this case could never occur. in that sense, this eip should be seen as a clarification of protocol behaviour in a previously undefined case rather than an explicit upgrade of consensus rules. this does not exclude all possible attack vectors, only the most serious one. further possible attack vectors via address collisions between contracts and eoas are: an attacker can convince a user to send funds to an account before it is deployed. some applications require this behaviour (e.g. state channels). a chain reorg can happen after a contract is deployed. if the reorg removes the contract deployment transaction the funds can still be accessed using the private key. a contract can self destruct, with the stated intention that erc20s (or other tokens) in the contract would be burned. however, they can now be accessed by a key for that address. all these scenarios are much harder to exploit for an attacker, and likely have much lower yield making the attacks unlikely to be economically viable. backwards compatibility it is unlikely that an attack like this has already occurred on the ethereum mainnet, or we would very likely have heard of it. it is inconceivable that someone would use this as a “feature” to make a contract an eoa at the same time, when they could simply do this by adding some methods to the contract instead of spending billions on building hardware to find hash collisions. private networks may have deployed contracts which also work as eoas at genesis and should check that this upgrade does not impact their workflows. clients might choose to disable this rule for rpc calls like eth_call and eth_estimategas as some multi-sig contracts use these calls to create transactions as if they originated from the multisig contract itself. test cases given a genesis allocation of address: 0x71562b71999873db5b286df957af199ec94617f7 balance: 1000000000000000000 // 1 ether nonce: 0, code: 0xb0b0face", every transaction sent by the private key corresponding to 0x715656... ( b71c71a67e1177ad4e901695e1b4b9ee17ae16c6668d313eac2f96dbcda3f291) should be rejected. these transaction must be rejected and not included in a block. reference implementation the following check must be added to the state transition checks after checking that the nonce of the sender is correct. the sender is the address recovered from the signature of the transaction. // make sure the sender is an eoa set ch to the codehash of the sender account if ch is not equal to emptycodehash then return errsendernoeoa end if a diff to implement eip-3607 in go-ethereum can be found here security considerations this eip is a strict security upgrade: it simply makes some transactions that were formerly valid now invalid. there is no legitimate use for such transactions, so there should be no security downsides. this eip can be implemented as a soft fork because the new validity rules are a strict superset of the previous validity rules. copyright copyright and related rights waived via cc0. citation please cite this document as: dankrad feist (@dankrad), dmitry khovratovich (@khovratovich), marius van der wijden (@mariusvanderwijden), "eip-3607: reject transactions from senders with deployed code," ethereum improvement proposals, no. 3607, june 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3607. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. hedera enhances network management with the dynamic address… | hedera hedera network services token service mint and configure tokens and accounts. consensus service verifiable timestamps and ordering of events. smart contracts run solidity smart contracts. hbar the hedera network's native cryptocurrency. insights how it works learn about hedera from end to end. explorers view live and historical data on hedera. dashboards analyze network activity and metrics. network nodes understand networks and node types. devs start building get started learn core concepts and build the future. documentation review the api and build using your favorite language. developer resources integrations plugins and microservices for hedera. fee estimator understand and estimate transaction costs. open source hedera is committed to open, transparent code. learning center learn about web3 and blockchain technologies. grants grants & accelerators for your project. bounties find bugs. submit a report. earn rewards. ecosystem ecosystem hedera ecosystem applications, developer tools, network explorers, and more. nft ecosystem metrics analyze on-chain and market nft ecosystem metrics. categories web3 applications connect into the innovative startups decentralizing the web on hedera. enterprise applications learn about the fortune 500 companies decentralizing the web on hedera. wallets & custodians create a hedera account to manage hbar, fungible tokens, and nfts. network explorers hedera mainnet and testnet graphical network explorers. developer tooling third-party apis, integrations, and plugins to build apps on hedera. grants & accelerators boost your project with support from the hedera ecosystem. partner program explore our partners to bring your vision into reality. hedera council over 30 highly diversified organizations govern hedera. use cases hedera solutions asset tokenization studio open source toolkit for tokenizing assets securely. stablecoin studio all-in-one toolkit for stablecoin solutions. hedera guardian auditable carbon markets and traceability. functional use cases data integrity & ai reliable, secure, and ethically governed insights. sustainability enabling fair carbon markets with trust. real-world asset tokenization seamless tokenization of real-world assets and digital at scale. consumer engagement & loyalty mint, distribute, and redeem loyalty rewards. decentralized identity maintain the lifecycle of credentials. decentralized logs scalable, real-time timestamped events. defi dapps built for the next-generation of finance. nfts low, fixed fees. immutable royalties. payments scalable, real-time, and affordable crypto-payments. hbar overview learn about hedera's token, hbar. treasury management hedera’s report of the hbar supply. governance decentralized governance hedera council see the world's leading organizations that own hedera. about meet hedera's board of directors and team. journey watch hedera's journey to build an empowered digital future for all. transparent governance public policy hedera's mission is to inform policy and regulation that impact the industry. meeting minutes immutably recorded on hedera. roadmap follow hedera's roadmap in its journey to build the future. resources company what's new partners papers careers media blog technical press podcast community events meetups store brand navigation quickstart hedera enhances network management with the dynamic address book technical dec 11, 2024 by mark blackman senior director of product, hashgraph every robust network relies on a registry of participants—whether it's dns, routing tables, or mac address tables. these registries are vital for enabling network participants to discover and connect seamlessly with each other. in decentralized or trustless environments, such registries must not only be reliable but also provable, secure, and capable of adapting to changes autonomously. on the hedera network, the address book acts as this registry, storing critical information such as: nodes participating in network gossip and consensus endpoints for sdk transactions consensus weight values derived from stake delegation the address book is currently managed by the hedera governing council, which oversees, approves, and signs all updates. while this centralized approach has been effective in maintaining the network's integrity, hedera’s commitment to decentralization necessitates a more autonomous and flexible solution. over time, this shift will empower node operators to manage their entries within the address book, fostering greater independence and scalability. enter the dynamic address book, introduced in hip-869. this transformative update simplifies address book management by enabling node operators to control their entries via transactions submitted to hedera’s mainnet. the result? reduced manual oversight, automated updates, and a significant step toward permissionless network participation. manual to automated management currently, managing the hedera address book requires action by the hedera governing council. for instance, adding or removing a node involves the council’s approval, configuration, and a network restart—an approach that can become inefficient as the network scales. the dynamic address book optimizes this process by: introducing new api endpoints for automated updates leveraging hedera transactions for transparent and verifiable address book changes reducing downtime by minimizing the need for network-wide resets implementation timeline the dynamic address book will be delivered in two stages: stage 1 (release 0.56): introduces the hapi endpoints to facilitate address book changes via signed transactions. the specifications or technical details in this blog are for stage 1. stage 2: implements full functionality, allowing daily address book updates aligned with the end of staking periods. dynamic address book: key features and benefits new hapi endpoints the dynamic address book introduces three key transaction types to manage nodes in the network. transaction description nodecreate adds a new node to the address book, effective after the next upgrade. nodeupdate updates an existing node’s details; changes are applied after the next upgrade (admin key changes apply immediately). nodedelete removes a node from the address book, effective after the next upgrade. node admin key to enable direct management, each node operator must use a node admin key to sign transactions related to their node. this key ensures that only authorized changes are made and shifts responsibility to node operators to manage their entries. api action required signatures nodecreate council signature + node admin key nodeupdate node admin key only nodedelete node admin key or council signature the impact of the dynamic address book the dynamic address book is a pivotal step in hedera's journey toward decentralization. it not only streamlines operations by reducing manual intervention but also lays the foundation for permissionless participation. this innovation empowers node operators with greater autonomy and transparency while also ensuring the registry remains secure, reliable, and verifiable. as hedera evolves, the dynamic address book will play a critical role in fostering a decentralized and scalable ecosystem. learn more to dive deeper into the dynamic address book and its implementation, refer to hip-869. share this back to blog what is grpc, grpc-web, and proxies? ed marquez pragmatic blockchain design patterns – integrating blockchain into business processes michiel mulders zero cost ethereumtransaction on success: hedera's new fee model for relay operators oliver thorn hedera adopts chainlink standard for cross-chain interoperability to accelerate ecosystem adoption hedera team hedera developer highlights march 2025 michiel mulders hedera release cycle overview ed marquez view all posts sign up for the newsletter connect with us transparency open source audits & standards sustainability commitment carbon offsets governance hedera council public policy treasury management meeting minutes llc agreement node requirements community events meetups hbar telegram developer discord twitter community support faq network status developer discord stackoverflow brand brand guidelines built on hedera logo hedera store about team partners journey roadmap careers contact general inquiry public relations © 2018-2025 hedera hashgraph, llc. all trademarks and company names are the property of their respective owners. all rights in the deutsche telekom mark are protected by deutsche telekom ag. all rights reserved. hedera uses the third party marks with permission. terms of use | privacy policy eip-3045: adds `basefee` to `eth_getunclebyblockhashandindex` ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3045: adds `basefee` to `eth_getunclebyblockhashandindex` authors abdelhamid bakhta (@abdelhamidbakhta) created 2020-10-14 discussion link https://ethereum-magicians.org/t/add-basefee-to-eth-getunclebyblockhashandindex/4829 requires eip-1474, eip-1559 table of contents simple summary abstract motivation specification eth_getunclebyblockhashandindex rationale backwards compatibility security considerations copyright simple summary add basefee field to eth_getunclebyblockhashandindex rpc endpoint response. abstract adds basefee property to the eth_getunclebyblockhashandindex json-rpc request result object. this property will contain the value of the base fee for any block after the eip-1559 fork. motivation eip-1559 introduces a base fee per gas in protocol. this value is maintained under consensus as a new field in the block header structure. users may need value of the base fee at a given block. base fee value is important to make gas price predictions more accurate. specification eth_getunclebyblockhashandindex description returns information about an uncle specified by block hash and uncle index position every block returned by this endpoint whose block number is before the eip-1559 fork block must not include a basefee field. every block returned by this endpoint whose block number is on or after the eip-1559 fork block must include a basefee field. parameters parameters remain unchanged. returns for the full specification of eth_getunclebyblockhashandindex see eip-1474. add a new json field to the result object for block headers containing a base fee (post eip-1559 fork block). {quantity} basefee base fee for this block example # request curl -x post --data '{ "id": 1559, "jsonrpc": "2.0", "method": "eth_getunclebyblockhashandindex", "params":["0xc6ef2fc5426d6ad6fd9e2a26abeab0aa2411b7ab17f30a99d3cb96aed1d1055b", "0x0"] }' # response { "id": 1559, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extradata": "0x0000000000000000000000000000000000000000000000000000000000000000", "basefee": "0x7" "gaslimit": "0x9f759", "gasused": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsbloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parenthash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateroot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totaldifficulty": "0x027f07", "transactions": [] "transactionsroot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [] } } rationale the addition of a single parameter instead of introducing a whole new endpoint was the simplest change that would be easiest to get integrated. for backward compatibility we decided to not include the base fee in the response for pre-1559 blocks. backwards compatibility backwards compatible. calls related to block prior to eip-1559 fork block will omit the base fee field in the response. security considerations the added field (basefee) is informational and does not introduce technical security issues. copyright copyright and related rights waived via cc0. citation please cite this document as: abdelhamid bakhta (@abdelhamidbakhta), "eip-3045: adds `basefee` to `eth_getunclebyblockhashandindex` [draft]," ethereum improvement proposals, no. 3045, october 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3045. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-820: pseudo-introspection registry contract ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-820: pseudo-introspection registry contract authors jordi baylina , jacques dafflon created 2018-01-05 requires eip-165, eip-214 table of contents simple summary abstract motivation specification erc-820 registry smart contract deployment transaction deployment method single-use registry deployment account registry contract address interface name set an interface for an address get an implementation of an interface for an address interface implementation (erc820implementerinterface) manager rationale backward compatibility test cases implementation copyright :information_source: erc-1820 has superseded erc-820. :information_source: erc-1820 fixes the incompatibility in the erc-165 logic which was introduced by the solidty 0.5 update. have a look at the official announcement, and the comments about the bug and the fix. apart from this fix, erc-1820 is functionally equivalent to erc-820. :warning: erc-1820 must be used in lieu of erc-820. :warning: simple summary this standard defines a universal registry smart contract where any address (contract or regular account) can register which interface it supports and which smart contract is responsible for its implementation. this standard keeps backward compatibility with erc-165. abstract this standard defines a registry where smart contracts and regular accounts can publish which functionalities they implement—either directly or through a proxy contract. anyone can query this registry to ask if a specific address implements a given interface and which smart contract handles its implementation. this registry may be deployed on any chain and shares the same address on all chains. interfaces with zeroes (0) as the last 28 bytes are considered erc-165 interfaces, and this registry shall forward the call to the contract to see if it implements the interface. this contract also acts as an erc-165 cache to reduce gas consumption. motivation there have been different approaches to define pseudo-introspection in ethereum. the first is erc-165 which has the limitation that it cannot be used by regular accounts. the second attempt is erc-672 which uses reverse ens. using reverse ens has two issues. first, it is unnecessarily complicated, and second, ens is still a centralized contract controlled by a multisig. this multisig theoretically would be able to modify the system. this standard is much simpler than erc-672, and it is fully decentralized. this standard also provides a unique address for all chains. thus solving the problem of resolving the correct registry address for different chains. specification erc-820 registry smart contract this is an exact copy of the code of the erc820 registry smart contract. /* erc820 pseudo-introspection registry contract * this standard defines a universal registry smart contract where any address * (contract or regular account) can register which interface it supports and * which smart contract is responsible for its implementation. * * written in 2018 by jordi baylina and jacques dafflon * * to the extent possible under law, the author(s) have dedicated all copyright * and related and neighboring rights to this software to the public domain * worldwide. this software is distributed without any warranty. * * you should have received a copy of the cc0 public domain dedication along * with this software. if not, see * . * * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗ * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗ * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║ * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║ * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝ * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝ * * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗ * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝ * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝ * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝ * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║ * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝ * */ pragma solidity 0.4.24; // iv is value needed to have a vanity address starting with `0x820`. // iv: 9513 /// @dev the interface a contract must implement if it is the implementer of /// some (other) interface for any address other than itself. interface erc820implementerinterface { /// @notice indicates whether the contract implements the interface `interfacehash` for the address `addr` or not. /// @param interfacehash keccak256 hash of the name of the interface /// @param addr address for which the contract will implement the interface /// @return erc820_accept_magic only if the contract implements `interfacehash` for the address `addr`. function canimplementinterfaceforaddress(bytes32 interfacehash, address addr) external view returns(bytes32); } /// @title erc820 pseudo-introspection registry contract /// @author jordi baylina and jacques dafflon /// @notice this contract is the official implementation of the erc820 registry. /// @notice for more details, see https://eips.ethereum.org/eips/eip-820 contract erc820registry { /// @notice erc165 invalid id. bytes4 constant invalid_id = 0xffffffff; /// @notice method id for the erc165 supportsinterface method (= `bytes4(keccak256('supportsinterface(bytes4)'))`). bytes4 constant erc165id = 0x01ffc9a7; /// @notice magic value which is returned if a contract implements an interface on behalf of some other address. bytes32 constant erc820_accept_magic = keccak256(abi.encodepacked("erc820_accept_magic")); mapping (address => mapping(bytes32 => address)) interfaces; mapping (address => address) managers; mapping (address => mapping(bytes4 => bool)) erc165cached; /// @notice indicates a contract is the `implementer` of `interfacehash` for `addr`. event interfaceimplementerset(address indexed addr, bytes32 indexed interfacehash, address indexed implementer); /// @notice indicates `newmanager` is the address of the new manager for `addr`. event managerchanged(address indexed addr, address indexed newmanager); /// @notice query if an address implements an interface and through which contract. /// @param _addr address being queried for the implementer of an interface. /// (if `_addr == 0` then `msg.sender` is assumed.) /// @param _interfacehash keccak256 hash of the name of the interface as a string. /// e.g., `web3.utils.keccak256('erc777token')`. /// @return the address of the contract which implements the interface `_interfacehash` for `_addr` /// or `0x0` if `_addr` did not register an implementer for this interface. function getinterfaceimplementer(address _addr, bytes32 _interfacehash) external view returns (address) { address addr = _addr == 0 ? msg.sender : _addr; if (iserc165interface(_interfacehash)) { bytes4 erc165interfacehash = bytes4(_interfacehash); return implementserc165interface(addr, erc165interfacehash) ? addr : 0; } return interfaces[addr][_interfacehash]; } /// @notice sets the contract which implements a specific interface for an address. /// only the manager defined for that address can set it. /// (each address is the manager for itself until it sets a new manager.) /// @param _addr address to define the interface for. (if `_addr == 0` then `msg.sender` is assumed.) /// @param _interfacehash keccak256 hash of the name of the interface as a string. /// for example, `web3.utils.keccak256('erc777tokensrecipient')` for the `erc777tokensrecipient` interface. /// @param _implementer contract address implementing _interfacehash for _addr. function setinterfaceimplementer(address _addr, bytes32 _interfacehash, address _implementer) external { address addr = _addr == 0 ? msg.sender : _addr; require(getmanager(addr) == msg.sender, "not the manager"); require(!iserc165interface(_interfacehash), "must not be a erc165 hash"); if (_implementer != 0 && _implementer != msg.sender) { require( erc820implementerinterface(_implementer) .canimplementinterfaceforaddress(_interfacehash, addr) == erc820_accept_magic, "does not implement the interface" ); } interfaces[addr][_interfacehash] = _implementer; emit interfaceimplementerset(addr, _interfacehash, _implementer); } /// @notice sets the `_newmanager` as manager for the `_addr` address. /// the new manager will be able to call `setinterfaceimplementer` for `_addr`. /// @param _addr address for which to set the new manager. /// @param _newmanager address of the new manager for `addr`. function setmanager(address _addr, address _newmanager) external { require(getmanager(_addr) == msg.sender, "not the manager"); managers[_addr] = _newmanager == _addr ? 0 : _newmanager; emit managerchanged(_addr, _newmanager); } /// @notice get the manager of an address. /// @param _addr address for which to return the manager. /// @return address of the manager for a given address. function getmanager(address _addr) public view returns(address) { // by default the manager of an address is the same address if (managers[_addr] == 0) { return _addr; } else { return managers[_addr]; } } /// @notice compute the keccak256 hash of an interface given its name. /// @param _interfacename name of the interface. /// @return the keccak256 hash of an interface name. function interfacehash(string _interfacename) external pure returns(bytes32) { return keccak256(abi.encodepacked(_interfacename)); } /* --erc165 related functions --*/ /* --developed in collaboration with william entriken. --*/ /// @notice updates the cache with whether the contract implements an erc165 interface or not. /// @param _contract address of the contract for which to update the cache. /// @param _interfaceid erc165 interface for which to update the cache. function updateerc165cache(address _contract, bytes4 _interfaceid) external { interfaces[_contract][_interfaceid] = implementserc165interfacenocache(_contract, _interfaceid) ? _contract : 0; erc165cached[_contract][_interfaceid] = true; } /// @notice checks whether a contract implements an erc165 interface or not. /// the result may be cached, if not a direct lookup is performed. /// @param _contract address of the contract to check. /// @param _interfaceid erc165 interface to check. /// @return `true` if `_contract` implements `_interfaceid`, false otherwise. function implementserc165interface(address _contract, bytes4 _interfaceid) public view returns (bool) { if (!erc165cached[_contract][_interfaceid]) { return implementserc165interfacenocache(_contract, _interfaceid); } return interfaces[_contract][_interfaceid] == _contract; } /// @notice checks whether a contract implements an erc165 interface or not without using nor updating the cache. /// @param _contract address of the contract to check. /// @param _interfaceid erc165 interface to check. /// @return `true` if `_contract` implements `_interfaceid`, false otherwise. function implementserc165interfacenocache(address _contract, bytes4 _interfaceid) public view returns (bool) { uint256 success; uint256 result; (success, result) = nothrowcall(_contract, erc165id); if (success == 0 || result == 0) { return false; } (success, result) = nothrowcall(_contract, invalid_id); if (success == 0 || result != 0) { return false; } (success, result) = nothrowcall(_contract, _interfaceid); if (success == 1 && result == 1) { return true; } return false; } /// @notice checks whether the hash is a erc165 interface (ending with 28 zeroes) or not. /// @param _interfacehash the hash to check. /// @return `true` if the hash is a erc165 interface (ending with 28 zeroes), `false` otherwise. function iserc165interface(bytes32 _interfacehash) internal pure returns (bool) { return _interfacehash & 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff == 0; } /// @dev make a call on a contract without throwing if the function does not exist. function nothrowcall(address _contract, bytes4 _interfaceid) internal view returns (uint256 success, uint256 result) { bytes4 erc165id = erc165id; assembly { let x := mload(0x40) // find empty storage location using "free memory pointer" mstore(x, erc165id) // place signature at beginning of empty storage mstore(add(x, 0x04), _interfaceid) // place first argument directly next to signature success := staticcall( 30000, // 30k gas _contract, // to addr x, // inputs are stored at location x 0x08, // inputs are 8 bytes long x, // store output over input (saves space) 0x20 // outputs are 32 bytes long ) result := mload(x) // load the result } } } deployment transaction below is the raw transaction which must be used to deploy the smart contract on any chain. 0xf90a2a8085174876e800830c35008080b909d7608060405234801561001057600080fd5b506109b7806100206000396000f30060806040526004361061008d5763ffffffff7c010000000000000000000000000000000000000000000000000000000060003504166329965a1d81146100925780633d584063146100bf5780635df8122f146100fc57806365ba36c114610123578063a41e7d5114610155578063aabbb8ca14610183578063b7056765146101a7578063f712f3e8146101e9575b600080fd5b34801561009e57600080fd5b506100bd600160a060020a036004358116906024359060443516610217565b005b3480156100cb57600080fd5b506100e0600160a060020a0360043516610512565b60408051600160a060020a039092168252519081900360200190f35b34801561010857600080fd5b506100bd600160a060020a036004358116906024351661055e565b34801561012f57600080fd5b506101436004803560248101910135610655565b60408051918252519081900360200190f35b34801561016157600080fd5b506100bd600160a060020a0360043516600160e060020a0319602435166106e3565b34801561018f57600080fd5b506100e0600160a060020a036004351660243561076d565b3480156101b357600080fd5b506101d5600160a060020a0360043516600160e060020a0319602435166107e7565b604080519115158252519081900360200190f35b3480156101f557600080fd5b506101d5600160a060020a0360043516600160e060020a03196024351661089c565b6000600160a060020a0384161561022e5783610230565b335b90503361023c82610512565b600160a060020a03161461029a576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b6102a38361091c565b156102f8576040805160e560020a62461bcd02815260206004820152601960248201527f4d757374206e6f74206265206120455243313635206861736800000000000000604482015290519081900360640190fd5b600160a060020a038216158015906103195750600160a060020a0382163314155b156104a15760405160200180807f4552433832305f4143434550545f4d414749430000000000000000000000000081525060130190506040516020818303038152906040526040518082805190602001908083835b6020831061038d5780518252601f19909201916020918201910161036e565b51815160209384036101000a6000190180199092169116179052604080519290940182900382207f249cb3fa000000000000000000000000000000000000000000000000000000008352600483018a9052600160a060020a0388811660248501529451909650938816945063249cb3fa936044808401945091929091908290030181600087803b15801561042057600080fd5b505af1158015610434573d6000803e3d6000fd5b505050506040513d602081101561044a57600080fd5b5051146104a1576040805160e560020a62461bcd02815260206004820181905260248201527f446f6573206e6f7420696d706c656d656e742074686520696e74657266616365604482015290519081900360640190fd5b600160a060020a03818116600081815260208181526040808320888452909152808220805473ffffffffffffffffffffffffffffffffffffffff19169487169485179055518692917f93baa6efbd2244243bfee6ce4cfdd1d04fc4c0e9a786abd3a41313bd352db15391a450505050565b600160a060020a03808216600090815260016020526040812054909116151561053c575080610559565b50600160a060020a03808216600090815260016020526040902054165b919050565b3361056883610512565b600160a060020a0316146105c6576040805160e560020a62461bcd02815260206004820152600f60248201527f4e6f7420746865206d616e616765720000000000000000000000000000000000604482015290519081900360640190fd5b81600160a060020a031681600160a060020a0316146105e557806105e8565b60005b600160a060020a03838116600081815260016020526040808220805473ffffffffffffffffffffffffffffffffffffffff19169585169590951790945592519184169290917f605c2dbf762e5f7d60a546d42e7205dcb1b011ebc62a61736a57c9089d3a43509190a35050565b60008282604051602001808383808284378201915050925050506040516020818303038152906040526040518082805190602001908083835b602083106106ad5780518252601f19909201916020918201910161068e565b6001836020036101000a038019825116818451168082178552505050505050905001915050604051809103902090505b92915050565b6106ed82826107e7565b6106f85760006106fa565b815b600160a060020a03928316600081815260208181526040808320600160e060020a031996909616808452958252808320805473ffffffffffffffffffffffffffffffffffffffff19169590971694909417909555908152600284528181209281529190925220805460ff19166001179055565b60008080600160a060020a038516156107865784610788565b335b91506107938461091c565b156107b85750826107a4828261089c565b6107af5760006107b1565b815b92506107df565b600160a060020a038083166000908152602081815260408083208884529091529020541692505b505092915050565b60008080610815857f01ffc9a70000000000000000000000000000000000000000000000000000000061093e565b9092509050811580610825575080155b1561083357600092506107df565b61084585600160e060020a031961093e565b909250905081158061085657508015155b1561086457600092506107df565b61086e858561093e565b90925090506001821480156108835750806001145b1561089157600192506107df565b506000949350505050565b600160a060020a0382166000908152600260209081526040808320600160e060020a03198516845290915281205460ff1615156108e4576108dd83836107e7565b90506106dd565b50600160a060020a03808316600081815260208181526040808320600160e060020a0319871684529091529020549091161492915050565b7bffffffffffffffffffffffffffffffffffffffffffffffffffffffff161590565b6040517f01ffc9a7000000000000000000000000000000000000000000000000000000008082526004820183905260009182919060208160088189617530fa9051909690955093505050505600a165627a7a723058204fc4461c9d5a247b0eafe0f9c508057bc0ad72bc24668cb2a35ea65850e10d3100291ba08208208208208208208208208208208208208208208208208208208208208200a00820820820820820820820820820820820820820820820820820820820820820 the strings of 820’s at the end of the transaction are the r and s of the signature. from this deterministic pattern (generated by a human), anyone can deduce that no one knows the private key for the deployment account. deployment method this contract is going to be deployed using the keyless deployment method—also known as nick’s method—which relies on a single-use address. (see nick’s article for more details). this method works as follows: generate a transaction which deploys the contract from a new random account. this transaction must not use eip-155 in order to work on any chain. this transaction must have a relatively high gas price to be deployed on any chain. in this case, it is going to be 100 gwei. set the v, r, s of the transaction signature to the following values: v: 27 r: 0x8208208208208208208208208208208208208208208208208208208208208200 s: 0x0820820820820820820820820820820820820820820820820820820820820820 those r and s values—made of a repeating pattern of 820’s—are predictable “random numbers” generated deterministically by a human. the values of r and s must be 32 bytes long each—or 64 characters in hexadecimal. since 820 is 3 characters long and 3 is not a divisor of 64, but it is a divisor of 63, the r and s values are padded with one extra character. the s value is prefixed with a single zero (0). the 0 prefix also guarantees that s < secp256k1n ÷ 2 + 1. the r value, cannot be prefixed with a zero, as the transaction becomes invalid. instead it is suffixed with a zero (0) which still respects the condition s < secp256k1n. we recover the sender of this transaction, i.e., the single-use deployment account. thus we obtain an account that can broadcast that transaction, but we also have the warranty that nobody knows the private key of that account. send exactly 0.08 ethers to this single-use deployment account. broadcast the deployment transaction. this operation can be done on any chain, guaranteeing that the contract address is always the same and nobody can use that address with a different contract. single-use registry deployment account 0xe6c244a1c10aa0085b0cf92f04cdad947c2988b8 this account is generated by reverse engineering it from its signature for the transaction. this way no one knows the private key, but it is known that it is the valid signer of the deployment transaction. to deploy the registry, 0.08 ethers must be sent to this account first. registry contract address 0x820b586c8c28125366c998641b09dcbe7d4cbf06 the contract has the address above for every chain on which it is deployed. raw metadata of ./contracts/erc820registry.sol ```json { "compiler": { "version": "0.4.24+commit.e67f0147" }, "language": "solidity", "output": { "abi": [ { "constant": false, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_interfacehash", "type": "bytes32" }, { "name": "_implementer", "type": "address" } ], "name": "setinterfaceimplementer", "outputs": [], "payable": false, "statemutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_addr", "type": "address" } ], "name": "getmanager", "outputs": [ { "name": "", "type": "address" } ], "payable": false, "statemutability": "view", "type": "function" }, { "constant": false, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_newmanager", "type": "address" } ], "name": "setmanager", "outputs": [], "payable": false, "statemutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_interfacename", "type": "string" } ], "name": "interfacehash", "outputs": [ { "name": "", "type": "bytes32" } ], "payable": false, "statemutability": "pure", "type": "function" }, { "constant": false, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceid", "type": "bytes4" } ], "name": "updateerc165cache", "outputs": [], "payable": false, "statemutability": "nonpayable", "type": "function" }, { "constant": true, "inputs": [ { "name": "_addr", "type": "address" }, { "name": "_interfacehash", "type": "bytes32" } ], "name": "getinterfaceimplementer", "outputs": [ { "name": "", "type": "address" } ], "payable": false, "statemutability": "view", "type": "function" }, { "constant": true, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceid", "type": "bytes4" } ], "name": "implementserc165interfacenocache", "outputs": [ { "name": "", "type": "bool" } ], "payable": false, "statemutability": "view", "type": "function" }, { "constant": true, "inputs": [ { "name": "_contract", "type": "address" }, { "name": "_interfaceid", "type": "bytes4" } ], "name": "implementserc165interface", "outputs": [ { "name": "", "type": "bool" } ], "payable": false, "statemutability": "view", "type": "function" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "addr", "type": "address" }, { "indexed": true, "name": "interfacehash", "type": "bytes32" }, { "indexed": true, "name": "implementer", "type": "address" } ], "name": "interfaceimplementerset", "type": "event" }, { "anonymous": false, "inputs": [ { "indexed": true, "name": "addr", "type": "address" }, { "indexed": true, "name": "newmanager", "type": "address" } ], "name": "managerchanged", "type": "event" } ], "devdoc": { "author": "jordi baylina and jacques dafflon", "methods": { "getinterfaceimplementer(address,bytes32)": { "params": { "_addr": "address being queried for the implementer of an interface. (if `_addr == 0` then `msg.sender` is assumed.)", "_interfacehash": "keccak256 hash of the name of the interface as a string. e.g., `web3.utils.keccak256('erc777token')`." }, "return": "the address of the contract which implements the interface `_interfacehash` for `_addr` or `0x0` if `_addr` did not register an implementer for this interface." }, "getmanager(address)": { "params": { "_addr": "address for which to return the manager." }, "return": "address of the manager for a given address." }, "implementserc165interface(address,bytes4)": { "params": { "_contract": "address of the contract to check.", "_interfaceid": "erc165 interface to check." }, "return": "`true` if `_contract` implements `_interfaceid`, false otherwise." }, "implementserc165interfacenocache(address,bytes4)": { "params": { "_contract": "address of the contract to check.", "_interfaceid": "erc165 interface to check." }, "return": "`true` if `_contract` implements `_interfaceid`, false otherwise." }, "interfacehash(string)": { "params": { "_interfacename": "name of the interface." }, "return": "the keccak256 hash of an interface name." }, "setinterfaceimplementer(address,bytes32,address)": { "params": { "_addr": "address to define the interface for. (if `_addr == 0` then `msg.sender` is assumed.)", "_implementer": "contract address implementing _interfacehash for _addr.", "_interfacehash": "keccak256 hash of the name of the interface as a string. for example, `web3.utils.keccak256('erc777tokensrecipient')` for the `erc777tokensrecipient` interface." } }, "setmanager(address,address)": { "params": { "_addr": "address for which to set the new manager.", "_newmanager": "address of the new manager for `addr`." } }, "updateerc165cache(address,bytes4)": { "params": { "_contract": "address of the contract for which to update the cache.", "_interfaceid": "erc165 interface for which to update the cache." } } }, "title": "erc820 pseudo-introspection registry contract" }, "userdoc": { "methods": { "getinterfaceimplementer(address,bytes32)": { "notice": "query if an address implements an interface and through which contract." }, "getmanager(address)": { "notice": "get the manager of an address." }, "implementserc165interface(address,bytes4)": { "notice": "checks whether a contract implements an erc165 interface or not. the result may be cached, if not a direct lookup is performed." }, "implementserc165interfacenocache(address,bytes4)": { "notice": "checks whether a contract implements an erc165 interface or not without using nor updating the cache." }, "interfacehash(string)": { "notice": "compute the keccak256 hash of an interface given its name." }, "setinterfaceimplementer(address,bytes32,address)": { "notice": "sets the contract which implements a specific interface for an address. only the manager defined for that address can set it. (each address is the manager for itself until it sets a new manager.)" }, "setmanager(address,address)": { "notice": "sets the `_newmanager` as manager for the `_addr` address. the new manager will be able to call `setinterfaceimplementer` for `_addr`." }, "updateerc165cache(address,bytes4)": { "notice": "updates the cache with whether the contract implements an erc165 interface or not." } } } }, "settings": { "compilationtarget": { "./contracts/erc820registry.sol": "erc820registry" }, "evmversion": "byzantium", "libraries": {}, "optimizer": { "enabled": true, "runs": 200 }, "remappings": [] }, "sources": { "./contracts/erc820registry.sol": { "content": "/* erc820 pseudo-introspection registry contract\n * this standard defines a universal registry smart contract where any address\n * (contract or regular account) can register which interface it supports and\n * which smart contract is responsible for its implementation.\n *\n * written in 2018 by jordi baylina and jacques dafflon\n *\n * to the extent possible under law, the author(s) have dedicated all copyright\n * and related and neighboring rights to this software to the public domain\n * worldwide. this software is distributed without any warranty.\n *\n * you should have received a copy of the cc0 public domain dedication along\n * with this software. if not, see\n * .\n *\n * ███████╗██████╗ ██████╗ █████╗ ██████╗ ██████╗\n * ██╔════╝██╔══██╗██╔════╝██╔══██╗╚════██╗██╔═████╗\n * █████╗ ██████╔╝██║ ╚█████╔╝ █████╔╝██║██╔██║\n * ██╔══╝ ██╔══██╗██║ ██╔══██╗██╔═══╝ ████╔╝██║\n * ███████╗██║ ██║╚██████╗╚█████╔╝███████╗╚██████╔╝\n * ╚══════╝╚═╝ ╚═╝ ╚═════╝ ╚════╝ ╚══════╝ ╚═════╝\n *\n * ██████╗ ███████╗ ██████╗ ██╗███████╗████████╗██████╗ ██╗ ██╗\n * ██╔══██╗██╔════╝██╔════╝ ██║██╔════╝╚══██╔══╝██╔══██╗╚██╗ ██╔╝\n * ██████╔╝█████╗ ██║ ███╗██║███████╗ ██║ ██████╔╝ ╚████╔╝\n * ██╔══██╗██╔══╝ ██║ ██║██║╚════██║ ██║ ██╔══██╗ ╚██╔╝\n * ██║ ██║███████╗╚██████╔╝██║███████║ ██║ ██║ ██║ ██║\n * ╚═╝ ╚═╝╚══════╝ ╚═════╝ ╚═╝╚══════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝\n *\n */\npragma solidity 0.4.24;\n// iv is value needed to have a vanity address starting with `0x820`.\n// iv: 9513\n\n/// @dev the interface a contract must implement if it is the implementer of\n/// some (other) interface for any address other than itself.\ninterface erc820implementerinterface {\n /// @notice indicates whether the contract implements the interface `interfacehash` for the address `addr` or not.\n /// @param interfacehash keccak256 hash of the name of the interface\n /// @param addr address for which the contract will implement the interface\n /// @return erc820_accept_magic only if the contract implements `interfacehash` for the address `addr`.\n function canimplementinterfaceforaddress(bytes32 interfacehash, address addr) external view returns(bytes32);\n}\n\n\n/// @title erc820 pseudo-introspection registry contract\n/// @author jordi baylina and jacques dafflon\n/// @notice this contract is the official implementation of the erc820 registry.\n/// @notice for more details, see https://eips.ethereum.org/eips/eip-820\ncontract erc820registry {\n /// @notice erc165 invalid id.\n bytes4 constant invalid_id = 0xffffffff;\n /// @notice method id for the erc165 supportsinterface method (= `bytes4(keccak256('supportsinterface(bytes4)'))`).\n bytes4 constant erc165id = 0x01ffc9a7;\n /// @notice magic value which is returned if a contract implements an interface on behalf of some other address.\n bytes32 constant erc820_accept_magic = keccak256(abi.encodepacked(\"erc820_accept_magic\"));\n\n mapping (address => mapping(bytes32 => address)) interfaces;\n mapping (address => address) managers;\n mapping (address => mapping(bytes4 => bool)) erc165cached;\n\n /// @notice indicates a contract is the `implementer` of `interfacehash` for `addr`.\n event interfaceimplementerset(address indexed addr, bytes32 indexed interfacehash, address indexed implementer);\n /// @notice indicates `newmanager` is the address of the new manager for `addr`.\n event managerchanged(address indexed addr, address indexed newmanager);\n\n /// @notice query if an address implements an interface and through which contract.\n /// @param _addr address being queried for the implementer of an interface.\n /// (if `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfacehash keccak256 hash of the name of the interface as a string.\n /// e.g., `web3.utils.keccak256('erc777token')`.\n /// @return the address of the contract which implements the interface `_interfacehash` for `_addr`\n /// or `0x0` if `_addr` did not register an implementer for this interface.\n function getinterfaceimplementer(address _addr, bytes32 _interfacehash) external view returns (address) {\n address addr = _addr == 0 ? msg.sender : _addr;\n if (iserc165interface(_interfacehash)) {\n bytes4 erc165interfacehash = bytes4(_interfacehash);\n return implementserc165interface(addr, erc165interfacehash) ? addr : 0;\n }\n return interfaces[addr][_interfacehash];\n }\n\n /// @notice sets the contract which implements a specific interface for an address.\n /// only the manager defined for that address can set it.\n /// (each address is the manager for itself until it sets a new manager.)\n /// @param _addr address to define the interface for. (if `_addr == 0` then `msg.sender` is assumed.)\n /// @param _interfacehash keccak256 hash of the name of the interface as a string.\n /// for example, `web3.utils.keccak256('erc777tokensrecipient')` for the `erc777tokensrecipient` interface.\n /// @param _implementer contract address implementing _interfacehash for _addr.\n function setinterfaceimplementer(address _addr, bytes32 _interfacehash, address _implementer) external {\n address addr = _addr == 0 ? msg.sender : _addr;\n require(getmanager(addr) == msg.sender, \"not the manager\");\n\n require(!iserc165interface(_interfacehash), \"must not be a erc165 hash\");\n if (_implementer != 0 && _implementer != msg.sender) {\n require(\n erc820implementerinterface(_implementer)\n .canimplementinterfaceforaddress(_interfacehash, addr) == erc820_accept_magic,\n \"does not implement the interface\"\n );\n }\n interfaces[addr][_interfacehash] = _implementer;\n emit interfaceimplementerset(addr, _interfacehash, _implementer);\n }\n\n /// @notice sets the `_newmanager` as manager for the `_addr` address.\n /// the new manager will be able to call `setinterfaceimplementer` for `_addr`.\n /// @param _addr address for which to set the new manager.\n /// @param _newmanager address of the new manager for `addr`.\n function setmanager(address _addr, address _newmanager) external {\n require(getmanager(_addr) == msg.sender, \"not the manager\");\n managers[_addr] = _newmanager == _addr ? 0 : _newmanager;\n emit managerchanged(_addr, _newmanager);\n }\n\n /// @notice get the manager of an address.\n /// @param _addr address for which to return the manager.\n /// @return address of the manager for a given address.\n function getmanager(address _addr) public view returns(address) {\n // by default the manager of an address is the same address\n if (managers[_addr] == 0) {\n return _addr;\n } else {\n return managers[_addr];\n }\n }\n\n /// @notice compute the keccak256 hash of an interface given its name.\n /// @param _interfacename name of the interface.\n /// @return the keccak256 hash of an interface name.\n function interfacehash(string _interfacename) external pure returns(bytes32) {\n return keccak256(abi.encodepacked(_interfacename));\n }\n\n /* --erc165 related functions --*/\n /* --developed in collaboration with william entriken. --*/\n\n /// @notice updates the cache with whether the contract implements an erc165 interface or not.\n /// @param _contract address of the contract for which to update the cache.\n /// @param _interfaceid erc165 interface for which to update the cache.\n function updateerc165cache(address _contract, bytes4 _interfaceid) external {\n interfaces[_contract][_interfaceid] = implementserc165interfacenocache(_contract, _interfaceid) ? _contract : 0;\n erc165cached[_contract][_interfaceid] = true;\n }\n\n /// @notice checks whether a contract implements an erc165 interface or not.\n /// the result may be cached, if not a direct lookup is performed.\n /// @param _contract address of the contract to check.\n /// @param _interfaceid erc165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceid`, false otherwise.\n function implementserc165interface(address _contract, bytes4 _interfaceid) public view returns (bool) {\n if (!erc165cached[_contract][_interfaceid]) {\n return implementserc165interfacenocache(_contract, _interfaceid);\n }\n return interfaces[_contract][_interfaceid] == _contract;\n }\n\n /// @notice checks whether a contract implements an erc165 interface or not without using nor updating the cache.\n /// @param _contract address of the contract to check.\n /// @param _interfaceid erc165 interface to check.\n /// @return `true` if `_contract` implements `_interfaceid`, false otherwise.\n function implementserc165interfacenocache(address _contract, bytes4 _interfaceid) public view returns (bool) {\n uint256 success;\n uint256 result;\n\n (success, result) = nothrowcall(_contract, erc165id);\n if (success == 0 || result == 0) {\n return false;\n }\n\n (success, result) = nothrowcall(_contract, invalid_id);\n if (success == 0 || result != 0) {\n return false;\n }\n\n (success, result) = nothrowcall(_contract, _interfaceid);\n if (success == 1 && result == 1) {\n return true;\n }\n return false;\n }\n\n /// @notice checks whether the hash is a erc165 interface (ending with 28 zeroes) or not.\n /// @param _interfacehash the hash to check.\n /// @return `true` if the hash is a erc165 interface (ending with 28 zeroes), `false` otherwise.\n function iserc165interface(bytes32 _interfacehash) internal pure returns (bool) {\n return _interfacehash & 0x00000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffff == 0;\n }\n\n /// @dev make a call on a contract without throwing if the function does not exist.\n function nothrowcall(address _contract, bytes4 _interfaceid)\n internal view returns (uint256 success, uint256 result)\n {\n bytes4 erc165id = erc165id;\n\n assembly {\n let x := mload(0x40) // find empty storage location using \"free memory pointer\"\n mstore(x, erc165id) // place signature at beginning of empty storage\n mstore(add(x, 0x04), _interfaceid) // place first argument directly next to signature\n\n success := staticcall(\n 30000, // 30k gas\n _contract, // to addr\n x, // inputs are stored at location x\n 0x08, // inputs are 8 bytes long\n x, // store output over input (saves space)\n 0x20 // outputs are 32 bytes long\n )\n\n result := mload(x) // load the result\n }\n }\n}\n", "keccak256": "0x8eecce3912a15087b3f5845d5a74af7712c93d0a8fcd6f2d40f07ed5032022ab" } }, "version": 1 } ``` interface name any interface name is hashed using keccak256 and sent to getinterfaceimplementer(). if the interface is part of a standard, it is best practice to explicitly state the interface name and link to this published erc-820 such that other people don’t have to come here to look up these rules. for convenience, the registry provides a function to compute the hash on-chain: function interfacehash(string _interfacename) public pure returns(bytes32) compute the keccak256 hash of an interface given its name. identifier: 65ba36c1 parameters _interfacename: name of the interface. returns: the keccak256 hash of an interface name. approved ercs if the interface is part of an approved erc, it must be named erc###xxxxx where ### is the number of the erc and xxxxx should be the name of the interface in camelcase. the meaning of this interface should be defined in the specified erc. examples: keccak256("erc20token") keccak256("erc777token") keccak256("erc777tokenssender") keccak256("erc777tokensrecipient") erc-165 compatible interfaces the compatibility with erc-165, including the erc165 cache, has been designed and developed with william entriken. any interface where the last 28 bytes are zeroes (0) shall be considered an erc-165 interface. erc-165 lookup anyone can explicitly check if a contract implements an erc-165 interface using the registry by calling one of the two functions below: function implementserc165interface(address _contract, bytes4 _interfaceid) public view returns (bool) checks whether a contract implements an erc-165 interface or not. note: the result is cached. if the cache is out of date, it must be updated by calling updateerc165cache. (see erc165 cache for more details.) identifier: f712f3e8 parameters _contract: address of the contract to check. _interfaceid: erc-165 interface to check. returns: true if _contract implements _interfaceid, false otherwise. function implementserc165interfacenocache(address _contract, bytes4 _interfaceid) public view returns (bool) checks whether a contract implements an erc-165 interface or not without using nor updating the cache. identifier: b7056765 parameters _contract: address of the contract to check. _interfaceid: erc-165 interface to check. returns: true if _contract implements _interfaceid, false otherwise. erc-165 cache whether a contract implements an erc-165 interface or not can be cached manually to save gas. if a contract dynamically changes its interface and relies on the erc-165 cache of the erc-820 registry, the cache must be updated manually—there is no automatic cache invalidation or cache update. ideally the contract should automatically update the cache when changing its interface. however anyone may update the cache on the contract’s behalf. the cache update must be done using the updateerc165cache function: function updateerc165cache(address _contract, bytes4 _interfaceid) public identifier: a41e7d51 parameters _contract: address of the contract for which to update the cache. _interfaceid: erc-165 interface for which to update the cache. private user-defined interfaces this scheme is extensible. you may make up your own interface name and raise awareness to get other people to implement it and then check for those implementations. have fun but please, you must not conflict with the reserved designations above. set an interface for an address for any address to set a contract as the interface implementation, it must call the following function of the erc-820 registry: function setinterfaceimplementer(address _addr, bytes32 _interfacehash, address _implementer) public sets the contract which implements a specific interface for an address. only the manager defined for that address can set it. (each address is the manager for itself, see the manager section for more details.) note: if _addr and _implementer are two different addresses, then: the _implementer must implement the erc820implementerinterface (detailed below). calling canimplementinterfaceforaddress on _implementer with the given _addr and _interfacehash must return the erc820_accept_magic value. note: the _interfacehash must not be an erc-165 interface—it must not end with 28 zeroes (0). note: the _addr may be 0, then msg.sender is assumed. this default value simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance. identifier: 29965a1d parameters _addr: address to define the interface for (if _addr == 0 them msg.sender: is assumed) _interfacehash: keccak256 hash of the name of the interface as a string, for example web3.utils.keccak256('erc777tokensrecipient') for the erc777tokensrecipient interface. _implementer: contract implementing _interfacehash for _addr. get an implementation of an interface for an address anyone may query the erc-820 registry to obtain the address of a contract implementing an interface on behalf of some address using the getinterfaceimplementer function. function getinterfaceimplementer(address _addr, bytes32 _interfacehash) public view returns (address) query if an address implements an interface and through which contract. note: if the last 28 bytes of the _interfacehash are zeroes (0), then the first 4 bytes are considered an erc-165 interface and the registry shall forward the call to the contract at _addr to see if it implements the erc-165 interface (the first 4 bytes of _interfacehash). the registry shall also cache erc-165 queries to reduce gas consumption. anyone may call the erc165updatecache function to update whether a contract implements an interface or not. note: the _addr may be 0, then msg.sender is assumed. this default value is consistent with the behavior of the setinterfaceimplementer function and simplifies interactions via multisigs where the data of the transaction to sign is constant regardless of the address of the multisig instance. identifier: aabbb8ca parameters _addr: address being queried for the implementer of an interface. (if _addr == 0 them msg.sender is assumed.) _interfacehash: keccak256 hash of the name of the interface as a string. e.g. web3.utils.keccak256('erc777token') returns: the address of the contract which implements the interface _interfacehash for _addr or 0x0 if _addr did not register an implementer for this interface. interface implementation (erc820implementerinterface) interface erc820implementerinterface { /// @notice indicates whether the contract implements the interface `interfacehash` for the address `addr`. /// @param addr address for which the contract will implement the interface /// @param interfacehash keccak256 hash of the name of the interface /// @return erc820_accept_magic only if the contract implements `ìnterfacehash` for the address `addr`. function canimplementinterfaceforaddress(bytes32 interfacehash, address addr) public view returns(bytes32); } any contract being registered as the implementation of an interface for a given address must implement said interface. in addition if it implements an interface on behalf of a different address, the contract must implement the erc820implementerinterface shown above. function canimplementinterfaceforaddress(bytes32 interfacehash, address addr) view public returns(bytes32); indicates whether a contract implements an interface (interfacehash) for a given address (addr). if a contract implements the interface (interfacehash) for a given address (addr), it must return erc820_accept_magic when called with the addr and the interfacehash. if it does not implement the interfacehash for a given address (addr), it must not return erc820_accept_magic. identifier: f0083250 parameters interfacehash: hash of the interface which is implemented addr: address for which the interface is implemented returns: erc820_accept_magic only if the contract implements ìnterfacehash for the address addr. the special value erc820_accept_magic is defined as the keccka256 hash of the string "erc820_accept_magic". bytes32 constant erc820_accept_magic = keccak256("erc820_accept_magic"); the reason to return erc820_accept_magic instead of a boolean is to prevent cases where a contract fails to implement the canimplementinterfaceforaddress but implements a fallback function which does not throw. in this case, since canimplementinterfaceforaddress does not exist, the fallback function is called instead, executed without throwing and returns 1. thus making it appear as if canimplementinterfaceforaddress returned true. manager the manager of an address (regular account or a contract) is the only entity allowed to register implementations of interfaces for the address. by default, any address is its own manager. the manager can transfer its role to another address by calling setmanager on the registry contract with the address for which to transfer the manager and the address of the new manager. setmanager function function setmanager(address _addr, address _newmanager) public sets the _newmanager as manager for the _addr address. the new manager will be able to call setinterfaceimplementer for _addr. if _newmanager is 0x0, the manager is reset to _addr itself as the manager. identifier: 5df8122f parameters _addr: address for which to set the new manager. _newmanager: the address of the new manager for _addr. (pass 0x0 to reset the manager to _addr.) getmanager function function getmanager(address _addr) public view returns(address) get the manager of an address. identifier: 3d584063 parameters _addr: address for which to return the manager. returns: address of the manager for a given address. rationale this standards offers a way for any type of address (externally owned and contracts) to implement an interface and potentially delegate the implementation of the interface to a proxy contract. this delegation to a proxy contract is necessary for externally owned accounts and useful to avoid redeploying existing contracts such as multisigs and daos. the registry can also act as a erc-165 cache in order to save gas when looking up if a contract implements a specific erc-165 interface. this cache is intentionally kept simple, without automatic cache update or invalidation. anyone can easily and safely update the cache for any interface and any contract by calling the updateerc165cache function. the registry is deployed using a keyless deployment method relying on a single-use deployment address to ensure no one controls the registry, thereby ensuring trust. backward compatibility this standard is backward compatible with erc-165, as both methods may be implemented without conflicting with each other. test cases please check the jbaylina/erc820 repository for the full test suite. implementation the implementation is available in the repo: jbaylina/erc820. copyright copyright and related rights waived via cc0. citation please cite this document as: jordi baylina , jacques dafflon , "erc-820: pseudo-introspection registry contract," ethereum improvement proposals, no. 820, january 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-820. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-1985: sane limits for certain evm parameters ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1985: sane limits for certain evm parameters authors alex beregszaszi (@axic), paweł bylica (@chfast) created 2018-08-01 discussion link https://ethereum-magicians.org/t/eip-1985-sane-limits-for-certain-evm-parameters/3224 table of contents abstract motivation specification rationale timestamp addresses memory size code size comparing current implementations backwards compatibility test cases implementation references todo copyright abstract introduce an explicit value range for certain evm parameters (such as gas limit, block number, block timestamp, size field when returning/copying data within evm). some of these already have an implicit value range due to various (practical) reasons. motivation having such an explicit value range can help in creating compatible client implementations, in certain cases it can also offer minor speed improvements, and can reduce the effort needed to create consensus critical test cases by eliminating unrealistic edge cases. specification if block.number >= {fork_block}, the following value ranges are introduced. they restrict the results (i.e. values pushed to the stack) of the instructions listed below. gas, gas limit, block gas limit is a range between 0 and 0x7fffffffffffffff (2**63 1, 9223372036854775807). it affects the following instructions: gaslimit (0x45), gas (0x5a). block number, timestamp is a range between 0 and 0x7fffffffffffffff (2**63 1, 9223372036854775807). it affects the following instructions: timestamp (0x42), number (0x43). account address is a range between 0 and 0xffffffffffffffffffffffffffffffffffffffff (2**160 1, 1461501637330902918203684832716283019655932542975) i.e. the address occupies the 160 low bits of the 256-bit value and the remaining top 96 bits must be zeros. it affects the following instructions: address (0x30), origin (0x32), caller (0x33), coinbase (0x41), create (0xf0), create2 (0xf5). buffer size, code size, memory size is a range between 0 and 0xffffffff (2**32 1, 4294967295). it affects the following instructions: calldatasize (0x36), codesize (0x38), extcodesize (0x3b), returndatasize (0x3d), msize (0x59), pc (0x58). rationale these limits have been: proposed by evmc implemented partially by certain clients, such as aleth, geth, parity and ethereumjs allowed by certain test cases in the ethereum testing suite and implicitly also allowed by certain assumptions, such as due to gas limits some of these values cannot grow past a certain limit most of the limits proposed in this document have been previously explored and tested in evmc. using the 2**63 1 constant to limit some of the ranges: allows using signed 64-bit integer type to represent it, what helps programming languages not having unsigned types, makes arithmetic simpler (e.g. checking out-of-gas conditions is simple as gas_counter < 0). timestamp the yellow paper defines the timestamp in block as “a scalar value equal to the reasonable output of unix’s time() at this block’s inception”. ieee std 1003.1-2001 (posix.1) leaves that definition implementation defined. addresses the size of addresses is specified in the yellow paper as 20 bytes. e.g. the coinbase instruction is specified to return hc ∈ 𝔹20 which has 20 bytes. memory size memory expansion cost is not linear and is determined by the following formula: cost = cost_per_word * number_of_words + (number_of_words ^ 2 / 512) expanding to over 2^32 1 bytes would cost 35184774742016 gas. this number fits into the gas limit imposed above (2 ^ 63 1) and would cost around 35184 ether in a transaction to exhaust, with a 1 gwei gas cost, which can be attained on mainnet. however, setting the limit 2^32 1 is beneficial from a vm design perspective and we believe limiting memory should be done via carefully selecting the block gas limit. code size eip-170 has implemented a code size limit of 0x6000, however even before that, it was practically impossible to deploy a code blob exceeding 2**32 1 bytes in size. comparing current implementations timestamp is implemented as a 64-bit value in aleth, geth and parity block gas limit is implemented as a 64-bit in aleth and geth memory, buffer and code sizes are implemented as 64-bit values in geth backwards compatibility all of these limits are already enforced mostly through the block gas limit. since the out of range case results in a transaction failure, there should not be a change in behaviour. test cases tba implementation tba references eip-92 proposed the transaction gas limit to be limited at 2**63 1 and had a lengthy discussion about other limits. eip-106 proposed the block gas limit to be limited at 2**63 1. todo does the gas limit apply to the gas argument for call instructions? copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), paweł bylica (@chfast), "eip-1985: sane limits for certain evm parameters [draft]," ethereum improvement proposals, no. 1985, august 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1985. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-2334: bls12-381 deterministic account hierarchy ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2334: bls12-381 deterministic account hierarchy authors carl beekhuizen created 2019-09-30 discussion link https://github.com/ethereum/eips/issues/2338 requires eip-2333 table of contents simple summary abstract a note on purpose motivation specification path purpose coin type account use eth2 specific parameters rationale eth2 specific parameters backwards compatibility copyright simple summary this eip defines the purpose of a given key, or family thereof, within a tree of keys. when combined with eip-2333, the combination of a seed and knowledge of the desired purpose of a key is sufficient to determine a key pair. abstract a standard for allocating keys generated by eip-2333 to a specific purpose. it defines a path which is a string that parses into the indices to be used when traversing the tree of keys that eip-2333 generates. a note on purpose this specification is designed not only to be an ethereum 2.0 standard, but one that is adopted by the wider community who have adopted bls signatures over bls12-381. it is therefore important also to consider the needs of the wider industry along with those specific to ethereum. as a part of these considerations, it is the intention of the author that this standard eventually migrate to a more neutral repository in the future. motivation ethereum 2.0 alongside many other projects will use bls signatures over bls12-381, an ietf proposed standard. this new scheme requires a new key derivation mechanism, which is established within eip-2333. this new scheme is incompatible with the current form of this specification (bip44) due to the: exclusive use of hardened keys, the increased number of keys per level, not using bip32 for key derivation. it is therefore necessary to establish a new path for traversing the eip-2333 key-tree. the path structure specified in this eip aims to be more general than bip44 by not having utxo-centric features which gave rise to the 4 different types of wallet paths being used within ethereum 1.0 and gave rise to (draft) eip-600 & eip-601 specification path the path traversed through the tree of keys is defined by integers (which indicate the sibling index) separated by / which denote ancestor relations. there are 4 levels (plus the master node) in the path and at least 4 (5 including the master node) must be used. m / purpose / coin_type / account / use notation the notation used within the path is specified within the eip-2333, but is summarized again below for convenience. m denotes the master node (or root) of the tree / separates the tree into depths, thus i / j signifies that j is a child of i purpose the purpose is set to 12381 which is the name of the new curve (bls12-381). in order to be in compliance with this standard, the eip-2333 must be implemented as the kdf and therefore, the purpose 12381 may not be used unless this is the case. coin type the coin_type here reflects the coin number for an individual coin thereby acting as a means of separating the keys used for different chains. account account is a field that provides the ability for a user to have distinct sets of keys for different purposes, if they so choose. this is the level at which different accounts for a single user should to be implemented. use this level is designed to provide a set of related keys that can be used for any purpose. the idea being that a single account has many uses which are related yet should remain separate for security reasons. it is required to support this level in the tree, although, for many purposes it will remain 0. eth2 specific parameters coin type the coin type used for the bls12-381 keys in ethereum 2 is 3600. validator keys each eth2 validator has two keys, one for withdrawals and transfers (called the withdrawal key), and the other for performing their duties as a validator (henceforth referred to as the signing key). the path for withdrawal keys is m/12381/3600/i/0 where i indicates the ith set of validator keys. the path for the signing key is m/12381/3600/i/0/0 where again, i indicates the ith set of validator keys. another way of phrasing this is that the signing key is the 0th child of the associated withdrawal key for that validator. note: if the above description of key paths is not feasible in a specific use case (eg. with secret-shared or custodial validators), then the affected keys may be omitted and derived via another means. implementations of this eip, must endeavour to use the appropriate keys for the given use case to the extent that is reasonably possible. (eg, in the case of custodial staking, the user making the deposits will follow this standard for their withdrawal keys which has no bearing on how the service provide derives the corresponding signing keys.) rationale purpose, coin_type, and account are widely-adopted terms as per bip43 and bip44 and therefore reusing these terms and their associated meanings makes sense. the purpose needs to be distinct from these standards as the kdf and path are not inter-compatible and 12381 is an obvious choice. account separates user activity into distinct categories thereby allowing users to separate their concerns however they desire. use will commonly be determined at the application level providing distinct keys for non-intersecting use cases. eth2 specific parameters a new coin type is chosen for eth2 keys to help ensure a clean separation between eth2 and eth1 keys. although the distinction between eth1 eth and eth2 eth is subtle, they are distinct entities and there are services which only distinguish between coins by their coin name (eg. ens’ multichain address resolution). 3600 is chosen specifically because it is the square of the eth1’s coin_type (3600==60^2) thereby signaling that it is second instantiation of ether the currency. the primary reason validators have separate signing and withdrawal keys is to allow for the different security concerns of actions within eth2. the signing key is given to the validator client where it signs messages as per the requirements of being a validator, it is therefore a “hot key”. if this key is compromised, the worst that can happen (locally) is that a slashable message is signed, resulting in the validator being slashed and forcibly exited. the withdrawal key is only needed when a validator wishes to perform an action not related to validating and has access to the full funds at stake for that validator. the withdrawal key therefore has higher security concerns and should be handled as a “cold key”. by having the signing key be a child of the withdrawal key, secure storage of the withdrawal key is sufficient to recover the signing key should the need arise. backwards compatibility bip43 and bip44 are the commonly used standards for this purpose within ethereum 1.0, however they have not been accepted as standards as yet. due to the use of a new kdf within eip-2333, a new path standard is required. this eip implements this, with minor changes. purpose 12381 paths do not support hardened keys and therefore the ' character is invalid. copyright copyright and related rights waived via cc0. citation please cite this document as: carl beekhuizen , "erc-2334: bls12-381 deterministic account hierarchy [draft]," ethereum improvement proposals, no. 2334, september 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2334. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6982: efficient default lockable tokens ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-6982: efficient default lockable tokens a gas-efficient approach to lockable erc-721 tokens authors francesco sullo (@sullof), alexe spataru (@urataps) created 2023-05-02 requires eip-165, eip-721 table of contents abstract motivation specification rationale backwards compatibility reference implementation security considerations copyright abstract this proposal introduces a lockable interface for erc-721 tokens that optimizes gas usage by eliminating unnecessary events. this interface forms the foundation for the creation and management of lockable erc-721 tokens. it provides a gas-efficient approach by emitting a defaultlocked(bool locked) event upon deployment, setting the initial lock status for all tokens, while individual locked(uint256 indexed tokenid, bool locked) events handle subsequent status changes for specific tokens. the interface also includes a view function locked(uint256 tokenid) to return the current lock status of a token, and a view function defaultlocked() to query the default status of a newly minted token. motivation existing lockable token proposals often mandate the emission of an event each time a token is minted. this results in unnecessary gas consumption, especially in cases where tokens are permanently locked from inception to destruction (e.g., soulbounds or non-transferable badges). this proposal offers a more gas-efficient solution that only emits events upon contract deployment and status changes of individual tokens. 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. the interface is defined as follows: // erc165 interfaceid 0x6b61a747 interface ierc6982 { /** * @dev must be emitted when the contract is deployed to establish the default lock status * for all tokens. also, must be emitted again if the default lock status changes, * to ensure the default status for all tokens (without a specific `locked` event) is updated. */ event defaultlocked(bool locked); /** * @dev must be emitted when the lock status of a specific token changes. * this status overrides the default lock status for that specific token. */ event locked(uint256 indexed tokenid, bool locked); /** * @dev returns the current default lock status for tokens. * the returned value must reflect the status indicated by the most recent `defaultlocked` event. */ function defaultlocked() external view returns (bool); /** * @dev returns the lock status of a specific token. * if no `locked` event has been emitted for the token, it must return the current default lock status. * the function must revert if the token does not exist. */ function locked(uint256 tokenid) external view returns (bool); } the erc-165 interfaceid is 0x6b61a747. rationale this standard seeks to optimize gas consumption by minimizing the frequency of event emission. the defaultlocked event is designed to establish the lock status for all tokens, thereby circumventing the need to emit an event each time a new token is minted. it’s crucial to note that the defaultlocked event can be emitted at any point in time, and is not restricted to only before the locked events are emitted. tokens may alter their behavior under certain circumstances (such as after a reveal), prompting the re-emission of the defaultlocked event to reflect the new default status. the primary objective here is to economize on gas usage by avoiding the need to emit a locked event for each token when the default status changes. the locked event is utilized to document changes in the lock status of individual tokens. the defaultlocked function returns the prevailing default lock status of a token. this function is beneficial as it fosters interaction with other contracts and averts potential conflicts with erc-5192, which is in its final stage. the locked function gives the current lock status of a particular token, further facilitating interaction with other contracts. if no changes have been made to a specific token id, this function should return the value provided by the defaultlocked function. bear in mind that a token being designated as “locked” doesn’t necessarily imply that it is entirely non-transferable. there might be certain conditions under which a token can still be transferred despite its locked status. primarily, the locked status relates to a token’s transferability on marketplaces and external exchanges. to illustrate, let’s consider the cruna protocol. in this system, an nft owner has the ability to activate what is termed an ‘protector’. this is essentially a secondary wallet with the unique privilege of initiating key transactions. upon setting an initiator, the token’s status is rendered ‘locked’. however, this does not impede the token’s transferability if the initiation for the transfer comes from the designated protector. backwards compatibility this standard is fully backwards compatible with existing erc-721 contracts. it can be easily integrated into existing contracts and will not cause any conflicts or disruptions. reference implementation an example implementation is located in the assets directory. it solves a specific use case: token’s owners losing the ownership when staking the asset in a pool. the implementation allow the pool to lock the asset, leaving the ownership to the owner. in the readme you can find more details about how to compile and test the contracts. security considerations this eip does not introduce any known security considerations. however, as with any smart contract standard, it is crucial to employ rigorous security measures in the implementation of this interface. copyright copyright and related rights waived via cc0. citation please cite this document as: francesco sullo (@sullof), alexe spataru (@urataps), "erc-6982: efficient default lockable tokens," ethereum improvement proposals, no. 6982, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6982. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-137: ethereum domain name service specification ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-137: ethereum domain name service specification authors nick johnson created 2016-04-04 table of contents abstract motivation specification overview name syntax namehash algorithm registry specification resolver specification contract address interface appendix a: registry implementation appendix b: sample resolver implementations built-in resolver standalone resolver public resolver appendix c: sample registrar implementation abstract this draft eip describes the details of the ethereum name service, a proposed protocol and abi definition that provides flexible resolution of short, human-readable names to service and resource identifiers. this permits users and developers to refer to human-readable and easy to remember names, and permits those names to be updated as necessary when the underlying resource (contract, content-addressed data, etc) changes. the goal of domain names is to provide stable, human-readable identifiers that can be used to specify network resources. in this way, users can enter a memorable string, such as ‘vitalik.wallet’ or ‘www.mysite.swarm’, and be directed to the appropriate resource. the mapping between names and resources may change over time, so a user may change wallets, a website may change hosts, or a swarm document may be updated to a new version, without the domain name changing. further, a domain need not specify a single resource; different record types allow the same domain to reference different resources. for instance, a browser may resolve ‘mysite.swarm’ to the ip address of its server by fetching its a (address) record, while a mail client may resolve the same address to a mail server by fetching its mx (mail exchanger) record. motivation existing specifications and implementations for name resolution in ethereum provide basic functionality, but suffer several shortcomings that will significantly limit their long-term usefulness: a single global namespace for all names with a single ‘centralised’ resolver. limited or no support for delegation and sub-names/sub-domains. only one record type, and no support for associating multiple copies of a record with a domain. due to a single global implementation, no support for multiple different name allocation systems. conflation of responsibilities: name resolution, registration, and whois information. use-cases that these features would permit include: support for subnames/sub-domains eg, live.mysite.tld and forum.mysite.tld. multiple services under a single name, such as a dapp hosted in swarm, a whisper address, and a mail server. support for dns record types, allowing blockchain hosting of ‘legacy’ names. this would permit an ethereum client such as mist to resolve the address of a traditional website, or the mail server for an email address, from a blockchain name. dns gateways, exposing ens domains via the domain name service, providing easier means for legacy clients to resolve and connect to blockchain services. the first two use-cases, in particular, can be observed everywhere on the present-day internet under dns, and we believe them to be fundamental features of a name service that will continue to be useful as the ethereum platform develops and matures. the normative parts of this document does not specify an implementation of the proposed system; its purpose is to document a protocol that different resolver implementations can adhere to in order to facilitate consistent name resolution. an appendix provides sample implementations of resolver contracts and libraries, which should be treated as illustrative examples only. likewise, this document does not attempt to specify how domains should be registered or updated, or how systems can find the owner responsible for a given domain. registration is the responsibility of registrars, and is a governance matter that will necessarily vary between top-level domains. updating of domain records can also be handled separately from resolution. some systems, such as swarm, may require a well defined interface for updating domains, in which event we anticipate the development of a standard for this. specification overview the ens system comprises three main parts: the ens registry resolvers registrars the registry is a single contract that provides a mapping from any registered name to the resolver responsible for it, and permits the owner of a name to set the resolver address, and to create subdomains, potentially with different owners to the parent domain. resolvers are responsible for performing resource lookups for a name for instance, returning a contract address, a content hash, or ip address(es) as appropriate. the resolver specification, defined here and extended in other eips, defines what methods a resolver may implement to support resolving different types of records. registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ens; the owner of a node in the ens registry is its registrar. registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts. resolving a name in ens is a two-step process. first, the ens registry is called with the name to resolve, after hashing it using the procedure described below. if the record exists, the registry returns the address of its resolver. then, the resolver is called, using the method appropriate to the resource being requested. the resolver then returns the desired result. for example, suppose you wish to find the address of the token contract associated with ‘beercoin.eth’. first, get the resolver: var node = namehash("beercoin.eth"); var resolver = ens.resolver(node); then, ask the resolver for the address for the contract: var address = resolver.addr(node); because the namehash procedure depends only on the name itself, this can be precomputed and inserted into a contract, removing the need for string manipulation, and permitting o(1) lookup of ens records regardless of the number of components in the raw name. name syntax ens names must conform to the following syntax: ::= | "." ::= any valid string label per [uts46](https://unicode.org/reports/tr46/) in short, names consist of a series of dot-separated labels. each label must be a valid normalised label as described in uts46 with the options transitional=false and usestd3asciirules=true. for javascript implementations, a library is available that normalises and checks names. note that while upper and lower case letters are allowed in names, the uts46 normalisation process case-folds labels before hashing them, so two names with different case but identical spelling will produce the same namehash. labels and domains may be of any length, but for compatibility with legacy dns, it is recommended that labels be restricted to no more than 64 characters each, and complete ens names to no more than 255 characters. for the same reason, it is recommended that labels do not start or end with hyphens, or start with digits. namehash algorithm before being used in ens, names are hashed using the ‘namehash’ algorithm. this algorithm recursively hashes components of the name, producing a unique, fixed-length string for any valid input domain. the output of namehash is referred to as a ‘node’. pseudocode for the namehash algorithm is as follows: def namehash(name): if name == '': return '\0' * 32 else: label, _, remainder = name.partition('.') return sha3(namehash(remainder) + sha3(label)) informally, the name is split into labels, each label is hashed. then, starting with the last component, the previous output is concatenated with the label hash and hashed again. the first component is concatenated with 32 ‘0’ bytes. thus, ‘mysite.swarm’ is processed as follows: node = '\0' * 32 node = sha3(node + sha3('swarm')) node = sha3(node + sha3('mysite')) implementations should conform to the following test vectors for namehash: namehash('') = 0x0000000000000000000000000000000000000000000000000000000000000000 namehash('eth') = 0x93cdeb708b7545dc668eb9280176169d1c33cfd8ed6f04690a0bcc88a93fc4ae namehash('foo.eth') = 0xde9b09fd7c5f901e23a3f19fecc54828e9c848539801e86591bd9801b019f84f registry specification the ens registry contract exposes the following functions: function owner(bytes32 node) constant returns (address); returns the owner (registrar) of the specified node. function resolver(bytes32 node) constant returns (address); returns the resolver for the specified node. function ttl(bytes32 node) constant returns (uint64); returns the time-to-live (ttl) of the node; that is, the maximum duration for which a node’s information may be cached. function setowner(bytes32 node, address owner); transfers ownership of a node to another registrar. this function may only be called by the current owner of node. a successful call to this function logs the event transfer(bytes32 indexed, address). function setsubnodeowner(bytes32 node, bytes32 label, address owner); creates a new node, sha3(node, label) and sets its owner to owner, or updates the node with a new owner if it already exists. this function may only be called by the current owner of node. a successful call to this function logs the event newowner(bytes32 indexed, bytes32 indexed, address). function setresolver(bytes32 node, address resolver); sets the resolver address for node. this function may only be called by the owner of node. a successful call to this function logs the event newresolver(bytes32 indexed, address). function setttl(bytes32 node, uint64 ttl); sets the ttl for a node. a node’s ttl applies to the ‘owner’ and ‘resolver’ records in the registry, as well as to any information returned by the associated resolver. resolver specification resolvers may implement any subset of the record types specified here. where a record types specification requires a resolver to provide multiple functions, the resolver must implement either all or none of them. resolvers must specify a fallback function that throws. resolvers have one mandatory function: function supportsinterface(bytes4 interfaceid) constant returns (bool) the supportsinterface function is documented in eip-165, and returns true if the resolver implements the interface specified by the provided 4 byte identifier. an interface identifier consists of the xor of the function signature hashes of the functions provided by that interface; in the degenerate case of single-function interfaces, it is simply equal to the signature hash of that function. if a resolver returns true for supportsinterface(), it must implement the functions specified in that interface. supportsinterface must always return true for 0x01ffc9a7, which is the interface id of supportsinterface itself. currently standardised resolver interfaces are specified in the table below. the following interfaces are defined: interface name interface hash specification addr 0x3b3b57de contract address name 0x691f3431 #181 abi 0x2203ab56 #205 pubkey 0xc8690233 #619 eips may define new interfaces to be added to this registry. contract address interface resolvers wishing to support contract address resources must provide the following function: function addr(bytes32 node) constant returns (address); if the resolver supports addr lookups but the requested node does not have an addr record, the resolver must return the zero address. clients resolving the addr record must check for a zero return value, and treat this in the same manner as a name that does not have a resolver specified that is, refuse to send funds to or interact with the address. failure to do this can result in users accidentally sending funds to the 0 address. changes to an address must trigger the following event: event addrchanged(bytes32 indexed node, address a); appendix a: registry implementation contract ens { struct record { address owner; address resolver; uint64 ttl; } mapping(bytes32=>record) records; event newowner(bytes32 indexed node, bytes32 indexed label, address owner); event transfer(bytes32 indexed node, address owner); event newresolver(bytes32 indexed node, address resolver); modifier only_owner(bytes32 node) { if(records[node].owner != msg.sender) throw; _ } function ens(address owner) { records[0].owner = owner; } function owner(bytes32 node) constant returns (address) { return records[node].owner; } function resolver(bytes32 node) constant returns (address) { return records[node].resolver; } function ttl(bytes32 node) constant returns (uint64) { return records[node].ttl; } function setowner(bytes32 node, address owner) only_owner(node) { transfer(node, owner); records[node].owner = owner; } function setsubnodeowner(bytes32 node, bytes32 label, address owner) only_owner(node) { var subnode = sha3(node, label); newowner(node, label, owner); records[subnode].owner = owner; } function setresolver(bytes32 node, address resolver) only_owner(node) { newresolver(node, resolver); records[node].resolver = resolver; } function setttl(bytes32 node, uint64 ttl) only_owner(node) { newttl(node, ttl); records[node].ttl = ttl; } } appendix b: sample resolver implementations built-in resolver the simplest possible resolver is a contract that acts as its own name resolver by implementing the contract address resource profile: contract dosomethinguseful { // other code function addr(bytes32 node) constant returns (address) { return this; } function supportsinterface(bytes4 interfaceid) constant returns (bool) { return interfaceid == 0x3b3b57de || interfaceid == 0x01ffc9a7; } function() { throw; } } such a contract can be inserted directly into the ens registry, eliminating the need for a separate resolver contract in simple use-cases. however, the requirement to ‘throw’ on unknown function calls may interfere with normal operation of some types of contract. standalone resolver a basic resolver that implements the contract address profile, and allows only its owner to update records: contract resolver { event addrchanged(bytes32 indexed node, address a); address owner; mapping(bytes32=>address) addresses; modifier only_owner() { if(msg.sender != owner) throw; _ } function resolver() { owner = msg.sender; } function addr(bytes32 node) constant returns(address) { return addresses[node]; } function setaddr(bytes32 node, address addr) only_owner { addresses[node] = addr; addrchanged(node, addr); } function supportsinterface(bytes4 interfaceid) constant returns (bool) { return interfaceid == 0x3b3b57de || interfaceid == 0x01ffc9a7; } function() { throw; } } after deploying this contract, use it by updating the ens registry to reference this contract for a name, then calling setaddr() with the same node to set the contract address it will resolve to. public resolver similar to the resolver above, this contract only supports the contract address profile, but uses the ens registry to determine who should be allowed to update entries: contract publicresolver { event addrchanged(bytes32 indexed node, address a); event contentchanged(bytes32 indexed node, bytes32 hash); ens ens; mapping(bytes32=>address) addresses; modifier only_owner(bytes32 node) { if(ens.owner(node) != msg.sender) throw; _ } function publicresolver(address ensaddr) { ens = ens(ensaddr); } function addr(bytes32 node) constant returns (address ret) { ret = addresses[node]; } function setaddr(bytes32 node, address addr) only_owner(node) { addresses[node] = addr; addrchanged(node, addr); } function supportsinterface(bytes4 interfaceid) constant returns (bool) { return interfaceid == 0x3b3b57de || interfaceid == 0x01ffc9a7; } function() { throw; } } appendix c: sample registrar implementation this registrar allows users to register names at no cost if they are the first to request them. contract fifsregistrar { ens ens; bytes32 rootnode; function fifsregistrar(address ensaddr, bytes32 node) { ens = ens(ensaddr); rootnode = node; } function register(bytes32 subnode, address owner) { var node = sha3(rootnode, subnode); var currentowner = ens.owner(node); if(currentowner != 0 && currentowner != msg.sender) throw; ens.setsubnodeowner(rootnode, subnode, owner); } } citation please cite this document as: nick johnson , "erc-137: ethereum domain name service specification," ethereum improvement proposals, no. 137, april 2016. [online serial]. available: https://eips.ethereum.org/eips/eip-137. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-4521: 721/20-compatible transfer ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-4521: 721/20-compatible transfer recommends a simple extension to make nfts compatible with apps and contracts that handle fungibles. authors ross campbell (@z0r0z) created 2021-12-13 discussion link https://ethereum-magicians.org/t/eip-4521-721-20-compatible-transfer/7903 requires eip-721 table of contents abstract motivation specification rationale backwards compatibility reference implementation security considerations copyright abstract erc-721, the popular standard for non-fungible tokens (nfts), includes send functions, such as transferfrom() and safetransferfrom(), but does not include a backwards-compatible transfer() found in fungible erc-20 tokens. this standard provides references to add such a transfer(). motivation this standard proposes a simple extension to allow nfts to work with contracts designed to manage erc-20s and many consumer wallets which expect to be able to execute a token transfer(). for example, if an nft is inadvertently sent to a contract that typically handles erc-20, that nft will be locked. it should also simplify the task for contract programmers if they can rely on transfer() to both handle erc-20 and nfts. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. the interface for erc-4521 transfer() must conform to erc-20 and resulting transfers must fire the transfer event as described in erc-721. function transfer(address to, uint256 tokenid) external returns (bool success); rationale replicating erc-20 transfer() with just a minor change to accurately reflect that a unique tokenid rather than fungible sum is being sent is desirable for code simplicity and to make integration easier. backwards compatibility this eip does not introduce any known backward compatibility issues. reference implementation a reference implementation of an erc-4521 transfer(): function transfer(address to, uint256 tokenid) public virtual returns (bool success) { require(msg.sender == ownerof[tokenid], "not_owner"); unchecked { balanceof[msg.sender]--; balanceof[to]++; } delete getapproved[tokenid]; ownerof[tokenid] = to; emit transfer(msg.sender, to, tokenid); success = true; } security considerations implementers must be sure to include the relevant return bool value for an erc-4521 in order to conform with existing contracts that use erc-20 interfaces, otherwise, nfts may be locked unless a safetransfer is used in such contracts. copyright copyright and related rights waived via cc0. citation please cite this document as: ross campbell (@z0r0z), "erc-4521: 721/20-compatible transfer [draft]," ethereum improvement proposals, no. 4521, december 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-4521. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2025: block rewards proposal for funding eth1.x ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-2025: block rewards proposal for funding eth1.x authors james hancock (@madeoftin) created 2019-04-20 discussion link https://github.com/madeoftin/eips/issues requires eip-1890 table of contents simple summary abstract motivation specification rewards distribution rationale rationale why a loan? loan repayment development loan accountability personal notes and disclosure coi disclaimer backwards compatibility test cases implementation faq why hardcoded values? why not allow current client implementors fund this work? (ef, consensys, parity, etc…) how will funding the devs be organized isn’t a loan considered a security, or is it? copyright simple summary add 0.0055 eth per block for 18 months (a total of 17050 eth) as a developer block reward reserved for funding specific ethereum1.x working groups. the working groups are state rent (750k), better sync (360k), finality gadget (360k), fee market (360k), testing infrastructure (360k). governance of the funds will be through a multisig of trusted individuals from the ecosystem including client teams, the foundation, and the community. eip-1890 proposes a mechanism to capture a portion of block rewards for sustainably funding ongoing network development. that eip sets values and addresses to zero and so does not actually collect any rewards. this proposal is to explicitly set those values and begin collecting a portion of block rewards for 18 months in order to fund ethereum 1.x working groups and organization efforts. this funding will be used to repay an initial loan provided by investors in the community funding this work with a small amount of interest. after 18 months the block reward would again reduce to zero. abstract this eip extends the mechanism established in eip-1890 to add 0.0055 eth to the block reward for a specific distribution period of 3,100,000 blocks(≈ 18 months). the recipient_address is set to a smart contract with hardcoded denominations that distributes incoming eth to a set of addresses for the purpose of eth1.x development. the emission schedule would start at the hard fork block number and continue for 3,100,000 blocks (≈ 18 months) at which point the address and amount would again return to 0. any further distribution would require a future hard fork. motivation the context for this proposal came from attending the core dev eth1.x meeting in berlin. development is needed to move eth1.x forward, and i observed that a lack of funding is the primary barrier to this work. this work can only be effectively conducted by working groups forming around these issues, and these working groups need funding in order to pay dedicated contractors and project managers. this proposal is a plan for funding these groups and supporting their operation. specification two constants will be introduced: reward_duration_in_blocks, which specifies the number of blocks after istanbul_block_height when the reward collection will terminate (i.e., at block istanbul_block_height + reward_duration_in_blocks) beneficiary_addresses, a list of tuples containing the address and the amount to be transferred to this address per block. these amounts will be determined as the loan is collected from participating organizations and the addresses for repayment will be specified by them. the total of the amounts will sum to 0.0055. at the end of reward_duration_in_blocks the loan will be completely repaid. reward_duration_in_blocks = 3100000 devfund_block_reward = 0.0055 beneficiary_addresses = [ (

, ), (

, ) ] beginning with block istanbul_block_height, the reward is added to the participating addresses within beneficiary_addresses at each block until the end of the reward_duration_in_blocks. if (current_block istanbul_block_height <= reward_duration_in_blocks) for beneficiary in beneficiary_addresses: beneficiary[0].balance += beneficiary[1] rewards distribution rationale development loan repayment: 0.005 eth per block: 15500 eth total development loan interest (10% total over the period, simple interest): 0.0005 eth per block: 1550 eth total total block reward increase = `0.0055` eth per block: 17050 eth total with a price of etheruem at $150.00 this will raise approx usd $2,325,000.00 for developing eth1.x over the next 18 months. *specific addresses to be determined faq why hardcoded values? rationale there has been great public debate concerning eip-1890, and one of the primary concerns is that it is difficult to evaluate the proposal without more complete information on how funds would be raised, how they would be administered, and how they would be used. there is a need for funding eth1.x development and it is currently unclear where those funds will come from. this proposal is intended to give a more comprehensive proposal for its funding. in the case that eth1.x is fully funded before the istanbul upgrade i will withdraw this eip. until that point i intend to continue championing this proposal as a valid funding mechanism for this work. why a loan? the eth1x initiative needs funding now, not in 18 months. a loan is necessary to complete certain stages of work before the funding mechanism begins to provide funds. a loan would provide this necessary funding today, and the investors willing to front this cost can recoup their contribution + a reward of a fixed interest rate for the risk on their loan. this arrangement will make it easier to find investors willing to participate who have sufficient funds. loan repayment there is a risk that the investors lose part of their contribution in the case that this eip is rejected by the community between the time the funds have been collected and the beginning of the payout schedule. in this case all remaining funds will be returned to the contributors. the interest on the loan is an incentive for investors to participate in spite of this risk. their downside is limited to the amount of funds spent before this eip is accepted or rejected, which should be no more than about 5%, while their upside consists of the 10% simple interest paid over the period. development loan development loan: 0.005 over 3.1 million blocks = 15500 eth funding working groups on 1.x funding contractors, coordinators, and project managers working groups defined with clear mandates budget working groups state rent (750k) better sync (360k) finality gadget (360k) fee market (360k) testing infrastructure (360k) eth1.x core dev gatherings funding hosting, traveling, and accommodations for necessary in-person gatherings of eth1.x core developers similar to the stanford and berlin eth1.x core dev meeting held earlier this year. at the end of the 18 months, the whole process would be torn down to prevent any internal tyranny of structurelessness forming within. faq how will the funding of the devs be organized? accountability the funds will be transferred into dai and secured in a multi-sig comprised of members of the community. representatives from the following groups will receive a key. eip editors geth parity consensys/pegasys (pegasys) the ethereum foundation (hudson jameson) community personal notes and disclosure i want to address any concerns about conflicts of interests directly. my participation with eth1.x currently has been as a volunteer. i am in talks about a possible funded role helping with testing and coordination. if my work for with eth1.x is funded, i will accept no additional funding collected by the mechanism proposed in this eip. eth1.x is the now of ethereum and i would like to see it succeed. this is the intent of my proposal. coi previously i was pm for tennagraph, a signalling solution for ethereum. an aragon grant funded this project and was distributed through giveth and an aragondao. i have not received any funding from the project beyond this grant. all of this is verifiable on-chain. i am stepping down from any paid role on the project to continue as an advisor. i am also stepping down as a moderator for stances as there is a coi moderating stances for eips i am working with directly. disclaimer i do not claim to represent the community with my views; any members who wish to join supporting me with this proposal are free to do so. this is as fair of a proposal as i can personally conceive. backwards compatibility this eip has no impact on backwards compatibility. test cases not implemented implementation not implemented faq why hardcoded values? why not us a smart contract with some governance mechanism to allow changing the distribution of funds? wouldn’t that be more flexible and effective? tldr: this eip is not about governance reform first, the payment of the loan will be hardcoded. once agreed, the terms must be kept to give the lenders confidence in the repayment of the loan. as long as blocks are created the debt will be paid back. this is the essence of a trustless smart contract. after the loan, there is the option to allow the amounts (limited to less than .05eth), and the locations (orgs that receive ecosystem funding) to be changed throughout the emission schedule. it is pretty easy to imagine a smart contract or dao fulfilling this role. however, there are three classes of options available today we can consider when governing changes. give the keys to the hands of the few (oligarchy) create a multisig that allows a group of individuals to update the smart contract. the most likely candidates for this are the core devs themselves, but it could also be a trusted few from the community/stakeholders. no matter how you slice it, there is a fundamental issue in deciding who gets to decide. there currently is not a trusted/adopted governance mechanism to make these decisions within the ethereum ecosytem. also, preventing changing the contract in self interest is difficult without a well-engineered governance system of checks and balances. this eip does not claim nor aim to solve these issues. give the keys to the hands of the many (plutarchy) allow ethereum holders with coin votes to update the smart contract. using holographic consensus could overcome the issue of voter turnout as it scales as participation scales, even to the size of the whole network. this has some benefits as the entire network can participate. however, the problem is that some individuals in the network are over represented – the wealthy. without a solution to identity that has been agreed to and implemented by the entire ethereum network, there is no way around giving more power in votes to the rich. this eip does not claim, nor aim to solve these issues. use ethereum governance as it is today criticisms or support aside, there is a system that governs ethereum today. it is a mix of rough consensus among core devs, miners running nodes, clients implementing changes, and stakeholders adopting those changes. it includes yelling or not yelling on twitter and reddit. it is complicated and i don’t claim to understand it. even without a clear view of how it works, there is evidence of its existence. this evidence is there are changes that have allowed to be implemented, and changes that have not allowed to be implemented in ethereum. i do not aim to change ethereum governance. because this eip has hardcoded values, it must go through the existing governance process, whatever that is, before it is implemented. it will then continue to operate until the end of the emission schedule. this is intentional. this makes it uncapturable. no party other then the ecosystem itself can modify the contract once it has been deployed. this eip is not about governance reform. why not allow current client implementors fund this work? (ef, consensys, parity, etc…) historically there has been a precedent that the ethereum foundation is solely responsible for funding the development of ethereum. this process has evolved as the development has become more distributed. aya miyaguchi observed in a recent coindesk article, “it really is not only ethereum foundation people who are building [ethereum]”. yes, we could rely on the ethereum foundation to fund eth1.x. but, why should we? this is a call for the network to come together and fund its own development. ethereum the network is not owned by any one organization or group of people. we are lucky to have the ef and i consider this eip in support of their coordination efforts. how will funding the devs be organized i do not profess to know the best way to organize these funds. there is work already in progress to organize these efforts championed by alexey akhunov. the following is a quote from a recent medium article: “going from funding a few implementation teams continuously and letting them do ‘their stuff’ to funding more specific and temporary initiatives requires looking at funding through different lenses. how much ‘due diligence’ and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. this is also solvable, and also more on this will come later (not in this post).” my suggestion would be to create an eth1.x core developer dao using daostack to coordinate membership and payment of the core devs, but ultimately they are capable of determining the system that works best for them. as long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now. isn’t a loan considered a security, or is it? i am not a lawyer and will seek further guidance from lawyers in the field on this point in particular. from the research i have done and conversations i have had there is a very good argument that a loan of this nature will not be considered a security by the us supreme court. as the result of reves et al. v . ernst young 1990, the court stated that a home loan, consumer financing, a loan secured by a lien on a small business or some assets of a small business, short term notes, or notes that formalize a debt incurred in the ordinary course of business are not securities. if the note resembles the items listed above (home loans, etc.) then the note will not be deemed a security. the supreme court provided four factors to determine if a note sufficiently resembles the types of notes that are not classified as securities. (source) family resemblance test 1) the intentions of the company and the individual—if the company raised money for general use in a business enterprise, then the note is more likely to be a security; if the individual agreed to the loan primarily for the profit the note was expected to generate, the note is more likely to be a security. 2) the plan of distribution—the more widely the note is offered, the more likely it is to be found a security. 3) the expectations of the investing public—if the investors thought they were investing in a business to make a profit on their investment, the note is more likely to be found a security. 4) other risk-reducing factor—if the note is collateralized or otherwise less risky than common notes, the note is less likely to be found to be a security. the loan is for the specific use of supporting eth1.x research and development. the distribution will not be widely offered and the note will be collateralized by the network itself, provided in eth and repaid in eth. in coordinating the collection of these funds recognise i may be legally liable for some of this work and i will do all of the due dilegence i can, seek legal counsel, and accept any legal repercussions resulting from this work. #### copyright copyright and related rights waived via cc0. citation please cite this document as: james hancock (@madeoftin), "eip-2025: block rewards proposal for funding eth1.x [draft]," ethereum improvement proposals, no. 2025, april 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2025. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. another ethereum ðξv update | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search another ethereum ðξv update posted by gavin wood on june 15, 2015 research & development been a while, i know, but then these are rather busy days. i'm writing this from a starbucks in shanghai sitting behind the great firewall, able to peep out only occasionally. i've been in asia with marek for the last couple of weeks, mainly for meetups, workshops and technical meetings. during this time, we've seen the release, struggle and survival of the olympic testnet, a very clear signal that a multi-client system would be far superior to the present monoculture. we've seen the beginning of the second external go audit, mainly for checking of regressions but also to offer comments and criticisms on aspects that have changed in the meantime such as go's network layer and sync strategy. we've seen mix and solidity continue to progress and mature. and through ongoing development and the progression of the apis we've seen all clients become cleaner, faster and more resilient. exchanges we've been continuing to work with exchanges, now marek and konstantin both provide substantial technical support, helping the coders from the exchanges understand the wide differences between using standard cryptocurrency apis and ethereum's smart-contract-based approach. in order to provide better support for them and maximise adoption, we've designed and introduced a middleware json rpc proxy allowing a much more familiar interface to ethereum for exchanges. c++ on the c++ side, we have introduced pv61, a new ethereum network protocol version (backwards compatible so as not to hamper the frontier release schedule for go) providing super-fast parallel hash-chain downloading and much more resilience to dirty hash-chain attacks. arkadiy is helping code that up for c++ with the hope that it can be worked into go before homestead. solidity, meanwhile, has progressed substantially: solidity can now structurally predict gas usage, optimise for storage access and code size very well, and support internal-function calls with dynamic types, together with a whole host of other features. liana continues hacking on that codebase together with christian. mix, under the guidance of aeron and jutta with avsa providing visual design insights and yann hacking, is seeing substantial ux polish and refactoring, with the general target being to have it be an ultra-usable, yet powerful, ide for contract development. ðapps may now be deployed to the network in a simple 3-stage process, and the state/blockchain management layer is becoming far improved, featuring a single-pane view from which you can easily see all transactions, calls and logs and propagate transactions between chain-refreshes easily. alex continues to work on the low-level network layer, now being helped by vlad. we had a summit in zug 3 weeks ago where i laid out the plans for our libp2p networking layer, and how the whisper and ethereum protocols fit into that. our first full-time developer on whisper, vlad will continue hacking at libp2p and whisper, making the protocol more resilient to various ethereum networking attacks whilst continuing the r&d for the p2p asynchronous non-endpoint-specific signalling protocol. pawel, working from warsaw, has been continuing on the jit evm and evm libraries, optimising stack usage and helping fix the stack depth issues we were seeing on mac os x. vladimir meanwhile continues his work on testing and marian on the netstats page which has recently proved its utility in more ways than one. those who have been experimenting with mining setups on the olympic testnet will probably recognise lefteris's work in taking over the ethash implementation, and updating, refactoring and generally supporting tim hughes' opencl implementation. special thanks to each of the members of the community who have helped one way or another with the development of this code. you know who you are (-: christoph, meanwhile, is now working on test coverage for the core classes, as well as helping fix various issues in the core. aside from working with the mix teams, arkadiy and marek, i've been coding up the new c++ wallet/secret store code (a revamped format and compatibility with go and python), optimising the core (import times for at least one gas-heavy block were recently measured as being ~10x faster than python and ~3x faster than go), bug fixing across the core, implementation of the new 'ethvm' binary for running the evm in standalone mode and the 'ethkey' binary for wallet management and, most recently, coding up a much better interactive console interface, similar to go's javascript console. i'm also hoping to get a much better blockchain download diagnostic display going soon in alethzero. auditing the internal audit of the c++ codebase has begun, with christoph working on tests for all core classes and arkadiy helping with some of the core optimisations. the secretstore and wallet classes have already been audited by christian, thereby giving credibility that the c++ client is reasonably secure for managing private keys. the c++ external audit will begin in three short weeks. since the substantial failure of the testnet caused by issues in only one of the three clients, including issues that survived two auditing procedures, it has become clear to us that auditing, external or internal, is no silver bullet. while we are committed to providing the very best software and will continue with our auditing programme, please let's be clear: there is nothing magical about the go client having gone through an auditing process. we are aiming to have all clients through at least a basic auditing process by the homestead release and i see no reason to use the go client over other clients (c++ or python) at this stage, nor, for the vast majority of users, during frontier. no clients come with any guarantees. indeed there's the argument that minority clients, being a smaller target, are less likely to be attacked. onwards we continue our preparations for the frontier release. while we're still uncertain of the precise release date, we are becoming increasingly happy at the resilience of the olympic testnet. as the olympic testnet's failure was ongoing, the adversity caused some reflection over how we might mitigate such problems in the future. the depth and duration of the consensus failure can, roughly speaking, be put down to two problems: firstly that there was a bug in the go codebase causing it to accept invalid blocks (in this case, blocks with an invalid proof-of-work nonce); secondly that there was a huge problem with upgrading the network since miners continued to mine on the 'bad' chain and were slow to upgrade their nodes so that they mined on the correct chain. essentially, the first was a forensic problem and the second an problem of organisation. to make sure this is never so deep nor broad in the future, i designed two new protocols: the bad chain canary and the bad block reporting api. the bad chain canary is a simple contract. it is controlled by a single key (though there may be several of them) and sits quietly until poked by its owner. i will be one such owner, vitalik and jeff two others and there will likely be fourth, christoph. when poked, it is given a blockhash and block number pair; this pair refers to a recent block on a bad chain. if they match the chain that the contract thinks it is sitting on, it puts itself in the "bad chain" state. this allows the ethereum core devs to inform everyone who is running a client on a bad chain (i.e. one that does not conform to the yellow paper due to a bug) that it is such. the default in clients (easily overridden) is not to mine on such chains (since to do so would be a waste of energy), but rather to inform the user that they should upgrade at their earliest opportunity. the bad block reporting api is a simple json rpc that allows a number of our nodes to run in a 'sentinel' mode. in this mode, if they come across a bad block, they automatically compile a standardised report of what went wrong including expected transaction receipts, vm traces, proof-of-work and block error information. this report is then instantly sent to a ðξv server where it can trigger an early warning system and, should the release tzar (that'd be taylor) deem it necessary, alert the core devs. through standardisation and usage of a simple format, it's designed so that we can easily code up a json-comparison engine to quickly diagnose where the consensus issue lies. one future job is to combine the two so that the json-rpc can also manage the reporting of canary information in this case, a user may set up a sentinel server to give them an email whenever the contract reports that mining has ceased and/or they should upgrade their node to continue mining. foundation finally, the three directors of the ethereum foundation (vitalik with three votes, then taylor and mihai with a vote each) will soon convene for, in vitalik's words, a "kind of great passing of the baton event". kelley, ðξv's indomitable coo, has been spearheading the search for proven candidates from a variety of fields who can add real value to the foundation both in terms of fundraising and of driving adoption. we're extremely grateful for all her hard work in this regard. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements gav’s ethereum ðξv update v | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search gav’s ethereum ðξv update v posted by gavin wood on march 2, 2015 research & development i was woken by vitalik's call at 5:55 this morning; pitch black outside, nighttime was still upon us. nonetheless, it was time to leave and this week had best start on the right foot. the 25-minute walk in darkness from the zug-based headquarters to the train station was wet. streetlights reflecting off the puddles on the clean swiss streets provided a picturesque, if quiet, march into town. i couldn't help but think the rain running down my face was a very liquid reminder of the impending seasonal change, and then, on consideration, how fast the last nine months had gone. solid foundations the last week was spent in zug by the ethereum foundation board and ðξv leadership: vitalik, mihai and taylor who officially form the founation's board, anthony and joseph as the other official advisors and aeron & jutta as the ðξv executive joined by jeff and myself wearing multiple hats of ðξv and advisory). the chief outcome of this was the dissemination of vitalik's superb plan to reform the foundation and turn it into a professional entity. the board will be recruited from accomplished professionals with minimal conflicts of interest; the present set of "founders" officially retired from those positions and a professional executive recruited, the latter process lead by joseph. anthony will take a greater ambassadorial role for ethereum in china and north america. conversely, ðξv will function much more as a department of the foundation's executive rather than a largely independent entity. finally, i presented the release strategy to the others; an event after which i've never seen quite so many photos taken of a whiteboard. needless to say, all was well received by the board and advisors. more information will be coming soon. as i write this, i'm sitting on a crowded early commuter train, vinay gupta in tow, who recently took on a much more substantive role this week as release coordinator. he'll be helping with release strategy and to keep you informed of our release process. this week, which might rather dramatically be described as 'pivotal' in the release process, will see jeff, vitalk and me sit around a table and develop all the poc-9 changes, related unit tests, and integrations in three days, joined by our indomitable master of testing, christoph. the outcome of this week will inform our announcement which will come later this week outlining in clear terms what we will be releasing and when. i'm sorry it has been so long without an update. the last 2 months has been somewhat busy, choked up with travel and meetings, with the remaining time soaked up by coding, team-leading and management. the team is now substantially formed; the formal security audit started four weeks ago; the bounty programme is running smoothly. the latter processes are the exceedingly capable hands of jutta and gustav. aeron, meanwhile will be stepping down as the ðξv head of finance and operations and assuming the role he was initially brought aboard for, system modelling. we'll hopefully be able to announce his successors next week (yes, that was plural; he has been doing the jobs of 2.5 people over the last few months). we are also in the process of forming partnerships with third parties in the industry; george, jutta and myself managing this process; i'm happy to announce that at least three exchanges will be supporting ether from day one on their trading platforms (details of which we'll annouce soon), with more exchanges to follow. marek and alex are providing technical supprt there with marek going so far as to make a substantial reference exchange implementation. i also finished the first draft of icap, the ethereum inter-exchange client address protocol, an iban-compatible system for referencing and transacting to client accounts aimed to streamline the process of transfering funds, worry-free between exchanges and, ultimately, make kyc and aml pains a thing of the past. the iban compatibility may even provide possibility of easy integration with existing banking infrastructure in some future. developments proof-of-concept releases vii and viii were released. natspec, "natural language specification format" and the basis of our transaction security was prototyped and integrated. under marek's watch, now helped by fabian, ethereum.js is truly coming of age with a near source-level compatibility with solidity on contract interaction and support for the typed abi with calling and events, the latter providing hassle-free state-change reporting. mix, our ide, underwent its first release and after some teethng issues is getting good use thanks to the excellent work done by arkadiy and yann. solidity had numerous features added and is swiftly approaching 1.0 status with christian, lefteris and liana to thank. marian's work goes ever forward on the network monitoring system while sven and heiko have been working diligently on the stress testing infrastructure which analyses and tests the peer network formation and performance. they'll soon be joined by alex and lefteris to accellerate this programme. so one of the major things that needed sorting for the next release is the proof-of-work algorithm that we'll use. this had a number of requirements, two of which were actually pulling in opposite directions, but basically it had to be light-client-friendly algorithm whose speed-of-mining is proportional to the io-bandwidth and which requires a considerable amount of ram to do so. there was a vague consensus that we (well.. vitalik and matthew) head in the direction of a hasimoto-like algorithm (a proof-of-work designed for the bitcoin blockchain that aims to be io-bound, meaning, roughly, that to make it go any faster, you'd need to add more memory rather than just sponsoring a smaller/faster asic). since our blockchain has a number of important differences with the bitcoin blockchain (mainly in transaction density), stemming from the extremely short 12s block time we're aiming for, we would have to use not the blockchain data itself like hashimoto but rather an artifcially created dataset, done with an algorithm known as dagger (yes, some will remember it as vitalik's first and flawed attempt at a memory-hard proof-of-work). while this looked like a good direction to be going in, a swift audit of vitalik and matt's initial algorithm by tim hughes (ex-director of technology at frontier developments and expert in low-level cpu and gpu operation and optimisation) showed major flaws. with his help, they were able to work together to devise a substantially more watertight algorithm that, we are confident to say, should make the job of developing an fpga/asic sufficiently difficult, especially given our determination to switch to a proof-of-stake system within the next 6-12 months. last, but not least, the new website was launched. kudos to ian and konstantin for mucking down and getting it done. next stop will be the developer site, which will be loosely based on the excellent resource at qt.io, the aim to provide a one-stop extravaganza of up to date reference documentation, curated tutorials, examples, recipes, downloads, issue tracking, and build status. onwards so, as alex, our networking maestro might say, these are exciting times. when deep in nitty gritty of development you sometimes forget quite how world-altering the technology you're creating is, which is probably just as well since the gravity of the matter at hand would be continually distracting. nonetheless, when one starts considering the near-term alterations that we can really bring one realises that the wave of change is at once unavoidable and heading straight for you. for what it's worth, i find an excellent accompaniment to this crazy life is the superb music of pretty lights. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-5539: revocation list registry ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5539: revocation list registry registry of revocation lists for revoking arbitrary data. authors philipp bolte (@strumswell), lauritz leifermann (@lleifermann), dennis von der bey (@dennisvonderbey) created 2022-08-26 discussion link https://ethereum-magicians.org/t/eip-5539-revocation-list-registry/10573 requires eip-712 table of contents abstract motivation specification definitions revocation management revocation list management owner management delegation management events meta transactions rationale why the concept of namespaces? why does a namespace always represent the initial owner address? backwards compatibility security considerations meta transactions rights management copyright abstract this eip proposes a set of methods and standards for a role-based registry of indicators aimed for usage in revocations. motivation revocation is a universally needed construct both in the traditional centralized and decentralized credential attestation. this eip aims to provide an interface to standardize a decentralized approach to managing and resolving revocation states in a contract registry. the largest problem with traditional revocation lists is the centralized aspect of them. most of the world’s crls rely on http servers as well as caching and are therefore vulnerable to known attack vectors in the traditional web space. this aspect severely weakens the underlying strong asymmetric key architecture in current pki systems. in addition, issuers in existing crl approaches are required to host an own instance of their public revocation list, as shared or centralized instances run the risk of misusage by the controlling entity. this incentivizes issuers to shift this responsibility to a third party, imposing the risk of even more centralization of the ecosystem (see cloudflare, aws). ideally, issuers should be able to focus on their area of expertise, including ownership of their revocable material, instead of worrying about infrastructure. we see value in a future of the internet where anyone can be an issuer of verifiable information. this proposal lays the groundwork for anyone to also own the lifecycle of this information to build trust in ecosystems. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. this eip specifies a contract called ethereumrevocationregistry that is deployed once and may then be commonly used by everyone. by default, an ethereum address may own and manage a multitude of revocation lists in a namespace that must contain the revocation states for a set of revocation keys. an owner of a namespace may allow delegates to manage one or more of its revocation lists. delegates must be removable by the respective list’s owner. in certain situations, an owner may also want to transfer a revocation list in a namespace and its management rights to a new owner. definitions namespace: a namespace is a representation of an ethereum address inside the registry that corresponds to its owners address. all revocation lists within a namespace are initially owned by the namespace’s owner address. revocation list: a namespace can contain a number of revocation lists. each revocation list is identified by a unique key of the type bytes32 that can be used to address it in combination with the namespace address. revocation key: a revocation list can contain a number of revocation keys of the type bytes32. in combination with the namespace address and the revocation list key, it resolves to a boolean value that indicates whether the revocation key is revoked or not. owner: an ethereum address that has modifying rights to revocation lists within its own and possibly foreign namespaces. an owner can give up modifying rights of revocation lists within its namespace by transferring ownership to another address. delegate: an ethereum address that received temporary access to a revocation list in a namespace. it has to be granted by the current owner of the revocation list in question. revocation management isrevoked must implement a function that returns the revocation status of a particular revocation key in a namespace’s revocation list. it may also respect the revocation lists revocation status. function isrevoked(address namespace, bytes32 list, bytes32 key) public view returns (bool); changestatus must implement a function to change the revocation status of a particular revocation key in a namespace’s revocation list function changestatus(bool revoked, address namespace, bytes32 revocationlist, bytes32 revocationkey) public; changestatussigned (see meta transactions) optional implements a function to change the revocation status of a particular revocation key in a namespace’s revocation list with a raw signature. function changestatussigned(bool revoked, address namespace, bytes32 revocationlist, bytes32 revocationkey, address signer, bytes calldata signature) public; changestatusdelegated optional implements a function to change the revocation status of a particular revocation key in a namespace’s revocation list by a revocation list’s delegate. function changestatusdelegated(bool revoked, address namespace, bytes32 revocationlist, bytes32 revocationkey) public; changestatusdelegatedsigned (see meta transactions) optional implements a function to change the revocation status of a particular revocation key in a namespace’s revocation list with a raw signature. function changestatusdelegatedsigned(bool revoked, address namespace, bytes32 revocationlist, bytes32 revocationkey, address signer, bytes calldata signature) public; changestatusesinlist optional implements a function to change multiple revocation statuses in a namespace’s revocation list at once. function changestatusesinlist(bool[] memory revoked, address namespace, bytes32 revocationlist, bytes32[] memory revocationkeys) public; changestatusesinlistsigned (see meta transactions) optional implements a function to change multiple revocation statuses in a namespace’s revocation list at once with a raw signature. function changestatusesinlistsigned(bool[] memory revoked, address namespace, bytes32 revocationlist, bytes32[] memory revocationkeys, address signer, bytes calldata signature) public; changestatusesinlistdelegated optional implements a function to change multiple revocation statuses in a namespace’s revocation list at once by a revocation list’s delegate. function changestatusesinlistdelegated(bool[] memory revoked, address namespace, bytes32 revocationlist, bytes32[] memory revocationkeys) public; changestatusesinlistdelegatedsigned (see meta transactions) optional implements a function to change multiple revocation statuses in a namespace’s revocation list at once with a raw signature generated by a revocation list’s delegate. function changestatusesinlistdelegatedsigned(bool[] memory revoked, address namespace, bytes32 revocationlist, bytes32[] memory revocationkeys, address signer, bytes calldata signature) public; revocation list management #### optional implements a function that returns the revocation status of a particular revocation list in a namespace. function listisrevoked(address namespace, bytes32 revocationlist) view public returns (bool); changeliststatus optional implements a function to change the revocation of a revocation list itself. if a revocation list is revoked, all its keys are considered revoked as well. function changeliststatus(bool revoked, address namespace, bytes32 revocationlist) public; changeliststatussigned (see meta transactions) optional implements a function to change the revocation of a revocation list itself with a raw signature. if a revocation list is revoked, all its keys are considered revoked as well. function changeliststatussigned(bool revoked, address namespace, bytes32 revocationlist, address signer, bytes calldata signature) public; owner management changelistowner optional implement a function to change the revocation status of a revocation list. if a revocation list is revoked, all keys in it are considered revoked. function changelistowner(address newowner, address namespace, bytes32 revocationlist) public; changelistownersigned (see meta transactions) optional implement a function to change the revocation status of a revocation list with a raw signature. if a revocation list is revoked, all keys in it are considered revoked. function changelistownersigned(address newowner, address namespace, bytes32 revocationlist, address signer, bytes calldata signature) public; delegation management addlistdelegate optional implements a function to add a delegate to an owner’s revocation list in a namespace. function addlistdelegate(address delegate, address namespace, bytes32 revocationlist) public; addlistdelegatesigned (see meta transactions) optional implements a function to add a delegate to an owner’s revocation list in a namespace with a raw signature. function addlistdelegatesigned(address delegate, address namespace, bytes32 revocationlist, address signer, bytes calldata signature) public; removelistdelegate optional implements a function to remove a delegate from an owner’s revocation list in a namespace. function removelistdelegate(address delegate, address owner, bytes32 revocationlist) public; removelistdelegatesigned (see meta transactions) optional implements a function to remove a delegate from an owner’s revocation list in a namespace with a raw signature. function removelistdelegatesigned(address delegate, address namespace, bytes32 revocationlist, address signer, bytes calldata signature) public; events revocationstatuschanged must be emitted when changestatus, changestatussigned, changestatusdelegated, changestatusdelegatedsigned, changestatusesinlist, changestatusesinlistsigned, changestatusesinlistdelegated, or changestatusesinlistdelegatedsigned was successfully executed. event revocationstatuschanged( address indexed namespace, bytes32 indexed revocationlist, bytes32 indexed revocationkey, bool revoked ); revocationlistownerchanged must be emitted when changelistowner or changelistownersigned was successfully executed. event revocationlistownerchanged( address indexed namespace, bytes32 indexed revocationlist, address indexed newowner ); revocationlistdelegateadded must be emitted when addlistdelegate or addlistdelegatesigned was successfully executed. event revocationlistdelegateadded( address indexed namespace, bytes32 indexed revocationlist, address indexed delegate ); revocationlistdelegateremoved must be emitted when removelistdelegate or removelistdelegatesigned was successfully executed. event revocationlistdelegateremoved( address indexed namespace, bytes32 indexed revocationlist, address indexed delegate ); revocationliststatuschanged must be emitted when changeliststatus or changeliststatussigned was successfully executed. event revocationliststatuschanged( address indexed namespace, bytes32 indexed revocationlist, bool revoked ); meta transactions this section uses the following terms: transaction signer: an ethereum address that signs arbitrary data for the contract to execute but does not commit the transaction. transaction sender: an ethereum address that takes signed data from a transaction signer and commits it wrapped with its own signature to the smart contract. an address (transaction signer) may be able to deliver a signed payload off-band to another address (transaction sender) that initiates the ethereum interaction with the smart contract. the signed payload must be limited to be used only once (signed hash + nonces). signed hash the signature of the transaction signer must conform eip-712. this helps users understand what the payload they’re signing consists of & it improves the protection against replay attacks. nonce this eip recommends the use of a dedicated nonce mapping for meta transactions. if the signature of the transaction sender and its meta contents are verified, the contract increases a nonce for this transaction signer. this effectively removes the possibility for any other sender to execute the same transaction again with another wallet. rationale why the concept of namespaces? this provides every ethereum address a reserved space, without the need to actively claim it in the contract. initially addresses only have owner access in their own namespace. why does a namespace always represent the initial owner address? the change of an owner of a list shouldn’t break the link to a revocation key in it, as already existing off-chain data may depend on it. backwards compatibility no backward compatibility issues were found. security considerations meta transactions the signature of signed transactions could potentially be replayed on different chains or deployed versions of the registry implementing this erc. this security consideration is addressed by the usage of eip-712 rights management the different roles and their inherent permissions are meant to prevent changes from unauthorized entities. the revocation list owner should always be in complete control over its revocation list and who has writing access to it. copyright copyright and related rights waived via cc0. citation please cite this document as: philipp bolte (@strumswell), lauritz leifermann (@lleifermann), dennis von der bey (@dennisvonderbey), "erc-5539: revocation list registry [draft]," ethereum improvement proposals, no. 5539, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5539. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7085: nft relationship enhancement ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7085: nft relationship enhancement establish relationships between nfts and setting quantifiable attributes for those relationships. authors guang (@xg1990) created 2023-05-02 discussion link https://ethereum-magicians.org/t/introducing-new-eip-nft-relationship-standard/14468 requires eip-721, eip-1155 table of contents abstract motivation specification setrelationship setattribute getattribute getattributenames getrelationship example usage rationale backwards compatibility reference implementation erc-165 interface support inftgraph interface nftgraph contract security considerations copyright abstract this proposal builds on erc-1155 and creates a standard for referring relationships and quantifiable attributes between non-isolated erc-721 or erc-1155 non-fungible tokens (nfts). it enables users to build a graph of nfts and set quantifiable attributes for each nft, facilitating more complex nft ecosystems. while a similar proposal exists for erc-721 tokens, it does not provide a way to establish quantifiable relationships or object attributes. motivation the current standard for nfts lacks the ability to establish relationships and attributes between tokens. this limitation makes it difficult for users to build more complex nft ecosystems that require referring relationships and quantifiable attributes between tokens. for example, a user may create a derivative nft that refers to the original nft and sets a quantifiable attribute for the relationship between the two nfts, but without a standardized way to establish relationships and attributes between nfts, managing these ecosystems becomes increasingly difficult and inefficient. this proposal aims to address this issue by extending the erc-721 and erc-1155 standards to include the ability to establish referring relationships and quantifiable attributes between nfts. by enabling users to build more complex nft ecosystems, this proposal will enhance the nft ecosystem and open up new possibilities for nft use cases. however, it’s important to consider potential drawbacks such as increased complexity and gas cost, and carefully design rules to mitigate these issues. specification this eip proposes the addition of five new functions to the erc-721 and erc-1155 standards: setrelationship, setattribute, getrelationship, getattribute, and getattributenames. these functions allow users to establish referring relationships and set quantifiable attributes between nfts. setrelationship the setrelationship function establishes a referring relationship between two nfts. it takes the following parameters: function setrelationship(uint256 _originalid, uint256 _derivativeid, uint256 _attribute) external; _originalid: the id of the original nft _derivativeid: the id of the derivative nft that refers to the original nft _attribute: the quantifiable attribute for this relationship, which defaults to 1 if not specified when called, this function establishes a referring relationship between the two nfts. setattribute the setattribute function sets a quantifiable attribute for an nft. it takes the following parameters: function setattribute(uint256 _id, string calldata _name, uint256 _value) external; _id: the id of the nft _name: the name of the attribute to be set _value: the value of the attribute to be set when called, this function sets a quantifiable attribute for the nft. getattribute the getattribute function allows anyone to retrieve the value of a specific attribute associated with an nft. it takes the following parameters: function getattribute(uint256 _id, string calldata _name) external view returns (bytes32); _id: the id of the nft for which you want to retrieve the attribute. _name: the name of the attribute you wish to retrieve. this function returns the value of the specified attribute as a bytes32 data type. getattributenames the getattributenames function allows anyone to retrieve the names of all attributes associated with an nft. it takes the following parameter: function getattributenames(uint256 _id) external view returns (bytes32[] memory); _id: the id of the nft for which you want to retrieve the attribute names. this function returns an array of bytes32 values representing the names of all attributes associated with the specified nft. getrelationship the getrelationship function allows anyone to retrieve the value of a referring relationship between two nfts. it takes the following parameters: function getrelationship(uint256 _originalid, uint256 _derivativeid) external view returns (uint256); _originalid: the id of the original nft. _derivativeid: the id of the derivative nft that refers to the original nft. this function returns the value of the referring relationship between the two nfts as a uint256 data type. example usage nftgraph nftcontract = nftgraph(addressofcontract); // retrieve the value of an attribute named "color" for nft with id 123 bytes32 colorvalue = nftcontract.getattribute(123, "color"); // retrieve the names of all attributes associated with nft with id 456 bytes32[] memory attributenames = nftcontract.getattributenames(456); by including these functions and methods in the specification, you establish a clear and standardized way for users and developers to read attributes associated with nfts. rationale in developing this eip, some key design decisions were made. for example, we limited the complexity of the relationship graph that can be created by only allowing for one referring relationship between two nfts. this helps to ensure that the graph remains manageable and does not become too complex to be useful. additionally, we kept the gas cost of setting attributes to a minimum by only allowing for one attribute to be set at a time. while there are currently no similar features in other blockchain languages or standards, we drew inspiration from the concept of graph theory, which is a branch of mathematics that studies the relationships between objects. by adding the ability to establish relationships between nfts and set quantifiable attributes for those relationships, we believe that the extended nft standard will become even more useful and versatile for nft creators and users. backwards compatibility this eip is designed to be fully backward-compatible with existing erc-721 and erc-1155 contracts and tokens. existing nft contracts and tokens will continue to function as they did before, and the new setrelationship and setattribute functions will only be available to contracts that explicitly implement this eip. reference implementation to assist in understanding and implementing this proposal, we provide a reference solidity interface and contract that define the functions for establishing relationships and reading attributes. developers can use this interface as a foundation for integrating the nft relationship enhancement into their own contracts. erc-165 interface support the nft relationship enhancement contract implements the erc-165 standard interface to allow for interface detection. this enables smart contracts and applications to check if a given contract supports the functions defined in this proposal before interacting with it. inftgraph interface // spdx-license-identifier: mit pragma solidity ^0.8.0; import "@openzeppelin/contracts/token/erc165/ierc165.sol"; // import ierc165 for interface detection interface inftgraph is ierc165 { // setrelationship: establishes relationships between nfts. function setrelationship(uint256 _originalid, uint256 _derivativeid, uint256 _attribute) external; // setattribute: sets quantifiable attributes for nfts. function setattribute(uint256 _id, string calldata _name, uint256 _value) external; // getrelationship: retrieves relationship values between nfts. function getrelationship(uint256 _originalid, uint256 _derivativeid) external view returns (uint256); // getattribute: retrieves the value of specific attributes associated with nfts. function getattribute(uint256 _id, string calldata _name) external view returns (bytes32); // getattributenames: retrieves all attribute names associated with an nft. function getattributenames(uint256 _id) external view returns (bytes32[] memory); } the inftgraph interface specifies the functions for setting relationships and attributes, as well as retrieving attribute information and relationship values. nftgraph contract // spdx-license-identifier: mit pragma solidity ^0.8.0; import "@openzeppelin/contracts/introspection/erc165.sol"; // import erc165 for interface detection import "./inftgraph.sol"; // import inftgraph interface contract nftgraph is inftgraph{ mapping(uint256 => mapping(uint256 => uint256)) public relationship; mapping(uint256 => mapping(bytes32 => bytes32)) public attributes; // implement the setrelationship and setattribute functions as described in the eip specification. // implement the supportsinterface function for erc-165. function supportsinterface(bytes4 interfaceid) public view override returns (bool) { return interfaceid == type(inftgraph).interfaceid || super.supportsinterface(interfaceid); } // additional implementation details... function getrelationship(uint256 _originalid, uint256 _derivativeid) external view returns (uint256) { return relationship[_originalid][_derivativeid]; } function getattribute(uint256 _id, string calldata _name) external view returns (bytes32) { return bytes32(attributes[_id][_name]); } function getattributenames(uint256 _id) external view returns (bytes32[] memory) { bytes32[] memory names = new bytes32[](attributes[_id].length); for (uint256 i = 0; i < attributes[_id].length; i++) { names[i] = bytes32(attributes[_id][i]); } return names; } function setrelationship(uint256 originalnft, uint256 derivativenft, uint256 relationshipvalue) public { require(originalnft != derivativenft, "original and derivative nfts must be different"); relationship[originalnft][derivativenft] = relationshipvalue; } function setattribute(uint256 nft, bytes32 attributename, bytes32 attributevalue) public { attributes[nft][attributename] = attributevalue; } } the nftgraph contract implements the functions specified in the inftgraph interface and provides storage for relationships and attributes. developers can use this reference interface and contract as a starting point for integrating the nft relationship enhancement functionality into their own projects. the interface provides a clear and standardized way to interact with the contract, promoting consistency and ease of integration. security considerations when implementing this proposal, contract developers should consider the following security aspects: validation of relationships: contracts utilizing the setrelationship function must ensure that the relationships being established are valid and authorized by the relevant parties. unauthorized or malicious relationships could lead to unintended consequences. attribute validation: contracts implementing the setattribute function should carefully validate attributes to prevent malicious or harmful values. invalid or unvalidated attributes could disrupt the functionality of the nft ecosystem. access control: contracts should implement appropriate access control mechanisms to restrict who can call critical functions, especially those that modify relationships or attributes. unauthorized access can lead to misuse or exploitation. reentrancy protection: consider adding reentrancy protection mechanisms to functions that modify relationships or attributes. reentrancy attacks could otherwise be exploited to manipulate contract behavior. by addressing these considerations, developers can enhance the security of their contracts and protect the integrity of the nft ecosystem. copyright copyright and related rights waived via cc0. citation please cite this document as: guang (@xg1990), "erc-7085: nft relationship enhancement [draft]," ethereum improvement proposals, no. 7085, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7085. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3508: transaction data opcodes ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-3508: transaction data opcodes authors alex papageorgiou (@alex-ppg) created 2021-04-16 discussion link https://ethereum-magicians.org/t/eip-draft-transaction-data-opcodes/6017 table of contents simple summary abstract motivation specification origindataload (0x47), origindatasize (0x48) and origindatacopy (0x49) rationale authcall (0xf7) interaction naming conventions instruction address space gas costs instruction space pollution backwards compatibility test cases security considerations introspective contracts denial-of-service attack multi-contract system gas reduction copyright simple summary provide access to original transaction data. abstract this eip introduces the following three evm instructions: origindataload, origindatasize, and origindatacopy. these three instructions are meant to provide access to the original transaction’s data payload, enabling a gas-efficient way of accessing large data payloads in cross-contract calls. motivation as the ethereum development scene matures, more ambitious and complex features are introduced into smart contracts more often than not requiring the utilization of complex and at times large data structures. given the inherent limits of the evm, however, transporting large data structures in between contracts is a costly task that can at times lead to even futile scenarios whereby the gas consumption of such an operation is impossible to execute within the gas limit bounds as well as without sacrificing a large chunk of eth to facilitate its gas cost. the purpose of this eip is to render these features viable by introducing a way via which multi-contract systems are able to access the same in-memory data source without necessarily transmitting the full payload between them. this eip enables elaborate smart contract features to become part of a larger call-chain by efficiently reading data from the original transaction payload rather than requiring the data to be passed in as call-level data. its inclusion will mainly benefit advanced trustless schemes to manifest, such as efficient verification of merkle patricia trees validating the storage value of a particular ethereum block or evm-based layer 2 solutions. a side-effect of this change is that smart contract systems relying entirely on origin data inherently guarantee that the data they receive has not been malformed by an intermediate smart contract call. specification origindataload (0x47), origindatasize (0x48) and origindatacopy (0x49) these instructions are meant to operate similarly to their call-prefixed counterparts with the exception that they instead operate on the original data of a transaction instead of the current call’s data. in detail: origindataload (0x47) performs similarly to calldataload (0x35) origindatasize (0x48) performs similarly to calldatasize (0x36) origindatacopy (0x49) performs similarly to calldatacopy (0x37) as the data is retrieved once again from the execution environment, the costs for the three instructions will be g_verylow, g_base and g_base + g_verylow * (number of words copied, rounded up) respectively. the transaction data the origindata* opcodes operate on will be equivalent to the calldata specified in the args* parameter to the nearest authcall (0xf7) up the stack. if there is no authcall in the stack then origindata* will operate on the transaction’s original data field. this interaction ensures full compatibility with eip-3074 and ensures that no form of discrimination is introduced back into the system by this eip e.g. by contracts entirely relying on origindata* and thus allowing only eoas to supply data to them. rationale authcall (0xf7) interaction the eip-3074 that will be part of the london fork has introduced a new call instruction called authcall (0xf7) that will replace a transaction’s origin (0x32) with the context variable authorized. the intention of authcall is to prevent discrimination between smart contracts and eoas which origin initially facilitated and as a result, it is sensible also replace the values retrieved by the origindata* opcodes to the ones used in the authcall. naming conventions the origin-prefixed instructions attempted to conform to the existing naming convention of call-prefixed instructions given the existence of the origin (0x32) instruction which is equivalent to the caller (0x33) instruction but on the original transaction’s context. instruction address space the instruction address space of the 0x30-0x3f has been exhausted by calls that already provide information about the execution context of a call so a new range had to be identified that is suitable for the purposes of the eip. given that the eip-1344 chainid opcode was included at 0x46, it made sense to include additional transaction-related data beyond it since the chain id is also included in transaction payloads apart from the blocks themselves, rendering the 0x46-0x4f address space reserved for more transaction-related data that may be necessary in the future, such as the eoa’s nonce. gas costs the opcodes origindataload (0x47), origindatasize (0x48), and origindatacopy (0x49) essentially perform the same thing as opcodes calldataload (0x35), calldatasize (0x36), and calldatacopy (0x37) respectively and thus share the exact same gas costs. instruction space pollution one can argue that multiple new evm instructions pollute the evm instruction address space and could cause issues in assigning sensible instruction codes to future instructions. this particular issue was assessed and a methodology via which the raw rlp encoded transaction may be accessible to the evm was ideated. this would future-proof the new instruction set as it would be usable for other members of the transaction that may be desired to be accessible on-chain in the future, however, it would also cause a redundancy in the origin opcode. backwards compatibility the eip does not alter or adjust existing functionality provided by the evm and as such, no known issues exist. test cases todo. security considerations introspective contracts atomically, the origindataload and origindatacopy values should be considered insecure as they can easily be spoofed by creating an entry smart contract with the appropriate function signature and arguments that consequently invokes other contracts within the call chain. in brief, one should always assume that tx.data != calldata and these instructions should not be used as an introspection tool alone. denial-of-service attack an initial concern that may arise from this eip is the additional contextual data that must be provided at the software level of nodes to the evm in order for it to be able to access the necessary data via the origindataload and origindatacopy instructions. this would lead to an increase in memory consumption, however, this increase should be negligible if at all existent given that the data of a transaction should already exist in memory as part of its execution process; a step in the overall inclusion of a transaction within a block. multi-contract system gas reduction given that most complex smart contract systems deployed on ethereum today rely on cross-contract interactions whereby values are passed from one contract to another via function calls, the origin-prefixed instruction set would enable a way for smart contract systems to acquire access to the original transaction data at any given step in the call chain execution which could result in cross-contract calls ultimately consuming less gas if the data passed between them is reduced as a side-effect of this change. the gas reduction, however, would be an implementation-based optimization that would also be solely applicable for rudimentary memory arguments rather than storage-based data, the latter of which is most commonly utilized in these types of calls. as a result, the overall gas reduction observed by this change will be negligible for most implementations. copyright copyright and related rights waived via cc0. citation please cite this document as: alex papageorgiou (@alex-ppg), "eip-3508: transaction data opcodes [draft]," ethereum improvement proposals, no. 3508, april 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3508. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2657: ephemeral testnet yolo ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant meta eip-2657: ephemeral testnet yolo authors james hancock (@madeoftin) created 2020-04-19 discussion link https://gitter.im/ethereum/allcoredevs table of contents abstract specification timeline client consensus -> implementation syncing instructions copyright disclaimer: this is for testing basic infrastructure. it will be nuked. it is not for deploying dapps, nor does it define what will go into mainnet. for information on network upgrades, please follow the relevant meta eips and ongoing discussion on ethereum/pm. abstract the specification for ephemeral testnet yolo. clients who wish to sync need to implement the following features into their client. it is for testing basic infrastructure and will be nuked. specification name: yolo id: yolo-v1 eip 2537 commit hash 5edff4ae6ff62c7e0bbfad624fc3d0ba7dc84392 eip 2315 commit hash e8accf22cdc5562d6982c560080c6cd6b7f94867 [ ] proposed [x] consensus to include. timeline deployed: june 3rd 2020 client consensus -> implementation yolo-v1 | client | signal | spec | merged | syncing | |————–|——–|——|——–|———| | besu | x | x | | | | ethereumjs | x | | | | | geth | x | x | x | x | | nethermind | x | x | | | | openethereum | x | x | | | | trinity | | | | | signal client intends to participate. (you are on the bus) spec client is satisfied with the proposed specification. (you agree with the direction) merge changes are implemented in the client and configurable for yolo. (you are ready to hit the gas and go) syncing client syncs with the network syncing instructions geth yolo v1 testnet is up and running https://yolonet.xyz/ support is baked into geth master branch via –yolov1 genesis config json is at https://yolonet.xyz/yolo.json ef bootnode at enode://9e1096aa59862a6f164994cb5cb16f5124d6c992cdbf4535ff7dea43ea1512afe5448dca9df1b7ab0726129603f1a3336b631e4d7a1a44c94daddd03241587f9@35.178.210.161:30303 stats page secret is yolov1, with geth you can –ethstats=’yournode:yolov1@stats.yolonet.xyz’ faucet is unauthenticated, you can reach it from the dashboard copyright copyright and related rights waived via cc0. citation please cite this document as: james hancock (@madeoftin), "eip-2657: ephemeral testnet yolo [draft]," ethereum improvement proposals, no. 2657, april 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2657. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2539: bls12-377 curve operations ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: core eip-2539: bls12-377 curve operations precompiles for bls12-377 curve operations authors alex vlasov (@shamatar), hujw77 (@hujw77) created 2020-02-26 discussion link https://ethereum-magicians.org/t/eip-2539-bls12-377-precompile-discussion-thread/4659 requires eip-1109, eip-2046 table of contents abstract proposed addresses table motivation specification fine points and encoding of base elements abi for operations prevention of ddos on error handling gas schedule rationale multiexponentiation as a separate call backwards compatibility important notes test cases reference implementation security considerations copyright abstract this precompile adds operation on bls12-377 curve (from zexe paper) as a precompile in a set necessary to efficiently perform operations such as bls signature verification and perform snarks verifications. unique properties of bls12-377 also later allow to have snarks that check bls12-377 pairing in an efficient way and allow e.g. constant-size bls signature aggregation. if block.number >= x we introduce nine separate precompiles to perform the following operations: bls12_377_g1add to perform point addition on a curve defined over prime field bls12_377_g1mul to perform point multiplication on a curve defined over prime field bls12_377_g1multiexp to perform multiexponentiation on a curve defined over prime field bls12_377_g2add to perform point addition on a curve twist defined over quadratic extension of the base field bls12_377_g2mul to perform point multiplication on a curve twist defined over quadratic extension of the base field bls12_377_g2multiexp to perform multiexponentiation on a curve twist defined over quadratic extension of the base field bls12_377_pairing to perform a pairing operations between a set of pairs of (g1, g2) points bls12_377_map_fp_to_g1 maps base field element into the g1 point bls12_377_map_fp2_to_g2 maps extension field element into the g2 point multiexponentiation operation is included to efficiently aggregate public keys or individual signer’s signatures during bls signature verification. proposed addresses table precompile address bls12_377_g1add 0x15 bls12_377_g1mul 0x16 bls12_377_g1multiexp 0x17 bls12_377_g2add 0x18 bls12_377_g2mul 0x19 bls12_377_g2multiexp 0x1a bls12_377_pairing 0x1b bls12_377_map_fp_to_g1 0x1c bls12_377_map_fp2_to_g2 0x1d motivation motivation of this precompile is to add a cryptographic primitive that allows to get 120+ bits of security for operations over pairing friendly curve compared to the existing bn254 precompile that only provides 80 bits of security. in addition it allows efficient one-time recursive proof aggregations, e.g. proofs about existence of bls12-377 based signature. specification curve parameters: bls12-377 curve is fully defined by the following set of parameters (coefficient a=0 for all bls12 curves): base field modulus = 0x01ae3a4617c510eac63b05c06ca1493b1a22d9f300f5138f1ef3622fba094800170b5d44300000008508c00000000001 b coefficient = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 main subgroup order = 0x12ab655e9a2ca55660b44d1e5c37b00159aa76fed00000010a11800000000001 extension tower: fp2 construction: fp quadratic non-residue = 0x01ae3a4617c510eac63b05c06ca1493b1a22d9f300f5138f1ef3622fba094800170b5d44300000008508bffffffffffc fp6/fp12 construction: fp2 cubic non-residue c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 fp2 cubic non-residue c1 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001 twist parameters: twist type: d b coefficient for twist c0 = 0x000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 b coefficient for twist c1 = 0x010222f6db0fd6f343bd03737460c589dc7b4f91cd5fd889129207b63c6bf8000dd39e5c1ccccccd1c9ed9999999999a generators: g1: x = 0x008848defe740a67c8fc6225bf87ff5485951e2caa9d41bb188282c8bd37cb5cd5481512ffcd394eeab9b16eb21be9ef y = 0x01914a69c5102eff1f674f5d30afeec4bd7fb348ca3e52d96d182ad44fb82305c2fe3d3634a9591afd82de55559c8ea6 g2: x c0 = 0x018480be71c785fec89630a2a3841d01c565f071203e50317ea501f557db6b9b71889f52bb53540274e3e48f7c005196 x c1 = 0x00ea6040e700403170dc5a51b1b140d5532777ee6651cecbe7223ece0799c9de5cf89984bff76fe6b26bfefa6ea16afe y c0 = 0x00690d665d446f7bd960736bcbb2efb4de03ed7274b49a58e458c282f832d204f2cf88886d8c7c2ef094094409fd4ddf y c1 = 0x00f8169fd28355189e549da3151a70aa61ef11ac3d591bf12463b01acee304c24279b83f5e52270bd9a1cdd185eb8f93 pairing parameters: |x| (miller loop scalar) = 0x8508c00000000001 x is negative = false fine points and encoding of base elements field elements encoding: to encode points involved in the operation one has to encode elements of the base field and the extension field. base field element (fp) is encoded as 64 bytes by performing bigendian encoding of the corresponding (unsigned) integer (top 16 bytes are always zeroes). 64 bytes are chosen to have 32 byte aligned abi (representable as e.g. bytes32[2] or uint256[2]). corresponding integer must be less than field modulus. for elements of the quadratic extension field (fp2) encoding is byte concatenation of individual encoding of the coefficients totaling in 128 bytes for a total encoding. for an fp2 element in a form el = c0 + c1 * v where v is formal quadratic non-residue and c0 and c1 are fp elements the corresponding byte encoding will be encode(c0) || encode(c1) where || means byte concatenation (or one can use bytes32[4] or uint256[4] in terms of solidity types). if encodings do not follow this spec anywhere during parsing in the precompile the precompile must return an error. encoding of points in g1/g2: points in either g1 (in base field) or in g2 (in extension field) are encoded as byte concatenation of encodings of the x and y affine coordinates. total encoding length for g1 point is thus 128 bytes and for g2 point is 256 bytes. point of infinity encoding: also referred as “zero point”. for bls12 curves point with coordinates (0, 0) (formal zeroes in fp or fp2) is not on the curve, so encoding of such point (0, 0) is used as a convention to encode point of infinity. encoding of scalars for multiplication operation: scalar for multiplication operation is encoded as 32 bytes by performing bigendian encoding of the corresponding (unsigned) integer. corresponding integer is not required to be less than or equal than main subgroup size. abi for operations abi for g1 addition g1 addition call expects 256 bytes as an input that is interpreted as byte concatenation of two g1 points (128 bytes each). output is an encoding of addition operation result single g1 point (128 bytes). error cases: either of points being not on the curve must result in error field elements encoding rules apply (obviously) input has invalid length abi for g1 multiplication g1 multiplication call expects 160 bytes as an input that is interpreted as byte concatenation of encoding of g1 point (128 bytes) and encoding of a scalar value (32 bytes). output is an encoding of multiplication operation result single g1 point (128 bytes). error cases: point being not on the curve must result in error field elements encoding rules apply (obviously) input has invalid length abi for g1 multiexponentiation g1 multiexponentiation call expects 160*k bytes as an input that is interpreted as byte concatenation of k slices each of them being a byte concatenation of encoding of g1 point (128 bytes) and encoding of a scalar value (32 bytes). output is an encoding of multiexponentiation operation result single g1 point (128 bytes). error cases: any of g1 points being not on the curve must result in error field elements encoding rules apply (obviously) input has invalid length abi for g2 addition g2 addition call expects 512 bytes as an input that is interpreted as byte concatenation of two g2 points (256 bytes each). output is an encoding of addition operation result single g2 point (256 bytes). error cases: either of points being not on the curve must result in error field elements encoding rules apply (obviously) input has invalid length abi for g2 multiplication g2 multiplication call expects 288 bytes as an input that is interpreted as byte concatenation of encoding of g2 point (256 bytes) and encoding of a scalar value (32 bytes). output is an encoding of multiplication operation result single g2 point (256 bytes). error cases: point being not on the curve must result in error field elements encoding rules apply (obviously) input has invalid length abi for g2 multiexponentiation g2 multiexponentiation call expects 288*k bytes as an input that is interpreted as byte concatenation of k slices each of them being a byte concatenation of encoding of g2 point (256 bytes) and encoding of a scalar value (32 bytes). output is an encoding of multiexponentiation operation result single g2 point (256 bytes). error cases: any of g2 points being not on the curve must result in error field elements encoding rules apply (obviously) input has invalid length abi for pairing pairing call expects 384*k bytes as an inputs that is interpreted as byte concatenation of k slices. each slice has the following structure: 128 bytes of g1 point encoding 256 bytes of g2 point encoding output is a 32 bytes where first 31 bytes are equal to 0x00 and the last byte is 0x01 if pairing result is equal to multiplicative identity in a pairing target field and 0x00 otherwise. error cases: invalid encoding of any boolean variable must result in error any of g1 or g2 points being not on the curve must result in error any of g1 or g2 points are not in the correct subgroup field elements encoding rules apply (obviously) input has invalid length abi for mapping fp element to g1 point field-to-curve call expects 64 bytes an an input that is interpreted as a an element of the base field. output of this call is 128 bytes and is g1 point following respective encoding rules. error cases: input has invalid length input is not a valid field element abi for mapping fp2 element to g2 point field-to-curve call expects 128 bytes an an input that is interpreted as a an element of the quadratic extension field. output of this call is 256 bytes and is g2 point following respective encoding rules. error cases: input has invalid length input is not a valid field element prevention of ddos on error handling this precompile performs extensive computations and in case of any errors during execution it must consume all gas from the the gas schedule for the corresponding operation. gas schedule assuming a constant 30 mgas/second following prices are suggested. g1 addition 600 gas g1 multiplication 12000 gas g2 addition 4500 gas g2 multiplication 55000 gas g1/g2 multiexponentiation multiexponentiations are expected to be performed by the peppinger algorithm (we can also say that is must be performed by peppinger algorithm to have a speedup that results in a discount over naive implementation by multiplying each pair separately and adding the results). for this case there was a table prepared for discount in case of k <= 128 points in the multiexponentiation with a discount cup max_discount for k > 128. to avoid non-integer arithmetic call cost is calculated as k * multiplication_cost * discount / multiplier where multiplier = 1000, k is a number of (scalar, point) pairs for the call, multiplication_cost is a corresponding single multiplication call cost for g1/g2. discounts table as a vector of pairs [k, discount]: [[1, 1200], [2, 888], [3, 764], [4, 641], [5, 594], [6, 547], [7, 500], [8, 453], [9, 438], [10, 423], [11, 408], [12, 394], [13, 379], [14, 364], [15, 349], [16, 334], [17, 330], [18, 326], [19, 322], [20, 318], [21, 314], [22, 310], [23, 306], [24, 302], [25, 298], [26, 294], [27, 289], [28, 285], [29, 281], [30, 277], [31, 273], [32, 269], [33, 268], [34, 266], [35, 265], [36, 263], [37, 262], [38, 260], [39, 259], [40, 257], [41, 256], [42, 254], [43, 253], [44, 251], [45, 250], [46, 248], [47, 247], [48, 245], [49, 244], [50, 242], [51, 241], [52, 239], [53, 238], [54, 236], [55, 235], [56, 233], [57, 232], [58, 231], [59, 229], [60, 228], [61, 226], [62, 225], [63, 223], [64, 222], [65, 221], [66, 220], [67, 219], [68, 219], [69, 218], [70, 217], [71, 216], [72, 216], [73, 215], [74, 214], [75, 213], [76, 213], [77, 212], [78, 211], [79, 211], [80, 210], [81, 209], [82, 208], [83, 208], [84, 207], [85, 206], [86, 205], [87, 205], [88, 204], [89, 203], [90, 202], [91, 202], [92, 201], [93, 200], [94, 199], [95, 199], [96, 198], [97, 197], [98, 196], [99, 196], [100, 195], [101, 194], [102, 193], [103, 193], [104, 192], [105, 191], [106, 191], [107, 190], [108, 189], [109, 188], [110, 188], [111, 187], [112, 186], [113, 185], [114, 185], [115, 184], [116, 183], [117, 182], [118, 182], [119, 181], [120, 180], [121, 179], [122, 179], [123, 178], [124, 177], [125, 176], [126, 176], [127, 175], [128, 174]] max_discount = 174 pairing operation cost of the pairing operation is 55000*k + 65000 where k is a number of pairs. fp-to-g1 mapping operation fp -> g1 mapping is 5500 gas. fp2-to-g2 mapping operation fp2 -> g2 mapping is 75000 gas rationale motivation section covers a total motivation to have operations over bls12-377 curve available. we also extend a rationale for move specific fine points. multiexponentiation as a separate call explicit separate multiexponentiation operation that allows one to save execution time (so gas) by both the algorithm used (namely peppinger algorithm) and (usually forgotten) by the fact that call operation in ethereum is expensive (at the time of writing), so one would have to pay non-negigible overhead if e.g. for multiexponentiation of 100 points would have to call the multipication precompile 100 times and addition for 99 times (roughly 138600 would be saved). backwards compatibility there are no backward compatibility questions. important notes subgroup checks subgroup check is mandatory during the pairing call. implementations should use fast subgroup checks: at the time of writing multiplication gas cost is based on double-and-add multiplication method that has a clear “worst case” (all bits are equal to one). for pairing operation it’s expected that implementation uses faster subgroup check, e.g. by using wnaf multiplication method for elliptic curves that is ~ 40% cheaper with windows size equal to 4. (tested empirically. savings are due to lower hamming weight of the group order and even lower hamming weight for wnaf. concretely, subgroup check for both g1 and g2 points in a pair are around 35000 combined). test cases due to the large test parameters space we first provide properties that various operations must satisfy. we use additive notation for point operations, capital letters (p, q) for points, small letters (a, b) for scalars. generator for g1 is labeled as g, generator for g2 is labeled as h, otherwise we assume random point on a curve in a correct subgroup. 0 means either scalar zero or point of infinity. 1 means either scalar one or multiplicative identity. group_order is a main subgroup order. e(p, q) means pairing operation where p is in g1, q is in g2. requeired properties for basic ops (add/multiply): commutativity: p + q = q + p additive negation: p + (-p) = 0 doubling p + p = 2*p subgroup check: group_order * p = 0 trivial multiplication check: 1 * p = p multiplication by zero: 0 * p = 0 multiplication by the unnormalized scalar (scalar + group_order) * p = scalar * p required properties for pairing operation: degeneracy e(p, 0*q) = e(0*p, q) = 1 bilinearity e(a*p, b*q) = e(a*b*p, q) = e(p, a*b*q) (internal test, not visible through abi) test vector for all operations are expanded in this csv files in matter-labs’ 1962 proposol. reference implementation there is a various choice of existing implementations of the curve operations. it may require extra work to add an abi: code bases with fixed parameters rust: matter-labs c++: matter-labs original implementation linked in zexe paper in rust: github.com/scipr-lab/zexe standalone in go: github.com/kilic/bls12-377 security considerations strictly following the spec will eliminate security implications or consensus implications in a contrast to the previous bn254 precompile. important topic is a “constant time” property for performed operations. we explicitly state that this precompile is not required to perform all the operations using constant time algorithms. copyright copyright and related rights waived via cc0. citation please cite this document as: alex vlasov (@shamatar), hujw77 (@hujw77), "eip-2539: bls12-377 curve operations [draft]," ethereum improvement proposals, no. 2539, february 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2539. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. devcon one postponed until further notice | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search devcon one postponed until further notice posted by george hallam on september 2, 2015 events unfortunately we were not able to secure the venue for devcon one in london on the dates desired (october 5th-8th). as a consequence we are postponing the event until further notice. please do not make travel plans at this time. updates will be forthcoming on the devcon one website . please standby for further information. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-684: revert creation in case of collision ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-684: revert creation in case of collision revert contract creation if address already has code authors vitalik buterin (@vbuterin), renan rodrigues de souza (@renansouza2) created 2023-03-20 table of contents abstract specification rationale backwards compatibility test cases security considerations copyright abstract this eip causes contract creation to throw an error when attempted at an address with pre-existing code. this prevents an attack consisting of deploying contract code and later changing the code arbitrarily by “creating” an account at that existing address. 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, or a nonzero code length, 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. rationale one of the core tenants of smart contracts is that its code will not change. however with sufficient computing power an attacker can change the code stored in an address to any other code, steal funds or execute other malicious activity. backwards compatibility this is an execution layer upgrade, and so it requires a hard fork. test cases given a genesis allocation of address : 0xd0bbec6d2c628b7e2e6d5556daa14a5181b604c5, balance : 1000000000000000000, // 1 ether nonce : 0, code : "", address : 0x7658771dc6af74a3d2f8499d349ff9c1a0df8826, balance : 0, nonce : 1, code : "0xb0b0face", a contract created in the first transaction from eoa 0xd0bbec6... (227bcc6959669226360814723ed739f1214201584b6a27409dfb8228b8be5f59), with no salt, should revert. security considerations this eip is a security upgrade: it enforces the imutability of deployed code. copyright copyright and related rights waived via cc0. citation please cite this document as: vitalik buterin (@vbuterin), renan rodrigues de souza (@renansouza2), "eip-684: revert creation in case of collision," ethereum improvement proposals, no. 684, march 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-684. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-5027: remove the limit on contract code size ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-5027: remove the limit on contract code size change the limit on contract size from 24576 to infinity authors qi zhou (@qizhou) created 2022-04-21 discussion link https://ethereum-magicians.org/t/eip-5027-unlimit-contract-code-size/9010 requires eip-170, eip-2929, eip-2930 table of contents abstract motivation specification parameters rationale gas metering backwards compatibility reference implementation security considerations copyright abstract remove the limit on the contract code size, i.e., only limit the contract code size by block gas limit, with minimal changes to existing code and proper gas metering adjustment to avoid possible attacks. motivation the motivation is to remove the limit on the code size so that users can deploy a large-code contract without worrying about splitting the contract into several sub-contracts. with the dramatic growth of dapplications, the functionalities of smart contracts are becoming more and more complicated, and thus, the sizes of newly developed contracts are steadily increasing. as a result, we are facing more and more issues with the 24576-bytes contract size limit. although several techniques such as splitting a large contract into several sub-contracts can alleviate the issue, these techniques inevitably increase the burden of developing/deploying/maintaining smart contracts. the proposal implements a solution to remove the existing 24576-bytes limit of the code size. further, the proposal aims to minimize the changes in the client implementation (e.g., geth) with proper gas metering to avoid abusing the node resources for contract-related opcodes, i.e, codesize (0x38)/codecopy (0x39)/extcodesize (0x3b)/extcodecopy (0x3c)/extcodehash (0x3f)/delegatecall (0xf4)/call (0xf1)/callcode (0xf2)/staticcall (0xfa)/create (0xf0)/create2 (0xf5); and no change to the existing structure of the ethereum state. specification parameters constant value fork_blknum tbd code_size_unit 24576 cold_account_code_access_cost_per_unit 2600 create_data_gas 200 if block.number >= fork_blknum, the contract creation initialization can return data with any length, but the contract-related opcodes will take extra gas as defined below: for codesize/codecopy/extcodesize/extcodehash, the gas is unchanged. for create/create2, if the newly created contract size > code_size_unit, the opcodes will take extra write gas as (code_size code_size_unit) * create_data_gas. for extcodecopy/call/callcode/delegatecall/staticcall, if the contract code size > code_size_unit, then the opcodes will take extra gas as (code_size 1) // code_size_unit * cold_account_code_access_cost_per_unit if the contract is not in accessed_code_in_addresses or 0 if the contract is in accessed_code_in_addresses, where // is the integer divide operator, and accessed_code_in_addresses: set[address] is a tranasction-context-wide set similar to access_addressses and accessed_storage_keys. when a transactoin execution begins, accessed_code_in_addresses will include tx.sender, tx.to, and all precompiles. when create/create2/extcodecopy/call/callcode/delegatecall/staticcall is called, immediately add the address to accessed_code_in_addresses. rationale gas metering the goal is to measure the cpu/io cost of the contract read/write operations reusing existing gas metering so that the resources will not be abused. for code-size-related opcodes (codesize/extcodesize), we would expect the client to implement a mapping from the hash of code to the size, so reading the code size of a large contract should still be o(1). for codecopy, the data is already loaded in memory (as part of call/callcode/delegatecall/staticcall), so we do not charge extra gas. for extcodehash, the value is already in the account, so we do not charge extra gas. for extcodecopy/call/callcode/delegatecall/staticcall, since it will read extra data from the database, we will additionally charge cold_account_code_access_cost_per_unit per extra code_size_unit. for create/create2, since it will create extra data to the database, we will additionally charge create_data_gas per extra bytes. backwards compatibility all existing contracts will not be impacted by the proposal. only contracts deployed before eip-170 could possibly be longer than the current max code size, and the reference implementation was able to successfully import all blocks before that fork. reference implementation the reference implementation on geth is available at 0001-unlimit-code-size.patch. security considerations tbd copyright copyright and related rights waived via cc0. citation please cite this document as: qi zhou (@qizhou), "eip-5027: remove the limit on contract code size [draft]," ethereum improvement proposals, no. 5027, april 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5027. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6188: nonce cap ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ review standards track: core eip-6188: nonce cap caps the nonce at 2^64-2 authors gavin john (@pandapip1) created 2022-12-20 requires eip-2929 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification eoa transactions create and create2 rationale backwards compatibility security considerations copyright abstract this eip caps the nonce at 2^64-2, reserving it for contracts with unusual behavior, as defined in other eips. motivation this eip is not terribly useful on its own, as it adds additional computation without any useful side effects. however, it can be used by other eips. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119 and rfc 8174. eoa transactions the nonce of a transaction originating from an eoa must be less than 2^64-2. if the nonce is either 2^64-1 or 2^64-2, the transaction must be invalid. create and create2 if a nonce would be incremented to 2^64-1 by create or create2, it is instead set to 2^64-2. 2^64-1 is reserved for alias or other special contracts. rationale capping a nonce allows for contracts with special properties to be created, with their functionality based on their contract code. as such, only one nonce needs to be reserved. backwards compatibility this eip requires a protocol upgrade, since it modifies consensus rules. the further restriction of nonce should not have an effect on accounts, as reaching a nonce of 2^64-2 is difficult. security considerations as it is not feasible for contract accounts to get to the nonce limit, any potential problems with opcodes that depend on the value of an account’s nonce can be safely ignored. copyright copyright and related rights waived via cc0. citation please cite this document as: gavin john (@pandapip1), "eip-6188: nonce cap [draft]," ethereum improvement proposals, no. 6188, december 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6188. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2700: javascript provider event emitter ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: interface eip-2700: javascript provider event emitter authors micah zoltu (@micahzoltu), erik marks (@rekmarks) created 2020-06-05 table of contents simple summary abstract motivation specification rfc-2119 interface rationale security considerations copyright simple summary a standard mechanism for javascript ethereum providers to notify clients about chain state changes when both are able to interface with each other via a shared javascript object. abstract this standard provides the description of an object that is made available to javascript applications which they can use to receive notifications from an ethereum provider. this standard only describes the notification mechanism, it does not specify the payloads that are valid nor does it specify how the client or the provider will discover or agree on payload content. how/where this ethereum provider object is exposed is left to future standards. motivation when working within a javascript runtime (such as nodejs, electron, browser, etc.) it may be possible for the runtime or a runtime plugin to inject objects into the runtime. someone authoring a runtime or a runtime plugin may choose to expose an ethereum provider to any javascript apps or scripts running within that runtime in order to provide notifications of blockchain state changes. in order to achieve maximum compatibility between the provider and the client, a standard is necessary for what the shape of that object is. specification rfc-2119 the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc-2119. interface interface ethereumprovider { on(eventname: string, listener: (...params: unknown[]) => void): void removelistener(eventname: string, listener: (...params: unknown[]) => void): void } the specific events that can be listened to and the shape of their listener callback functions is left to be defined in separate standards. if on is called with an eventname that the provider is familiar with then the provider must call the provided listener when the named event occurs. if the same listener is added multiple times to the same event via on, the provider may choose to either callback the listener one time or one time per call to on. if removelistener is called with an eventname and listener that was previously added via on then the provider must decrease the number of times it calls the listener per event by one. rationale this eip is mostly a retrospective eip meaning it codifies an already existing specification so there isn’t a lot of room for improving things such as by using a discriminated union object for listener parameters or having a tighter definition of on. the specific events are intentionally left out of this specification as that set will be an ever-evolving collection and having the first few listed here doesn’t add value to this specification (especially if, over time, the first few end up deprecated or unused). security considerations the relationship between ethereum provider and client is a trusted one, where it is assumed that the user implicitly trusts the ethereum provider which is how it managed to get injected into the client, or the client expressly pulled in a connection to it. copyright copyright and related rights waived via cc0. citation please cite this document as: micah zoltu (@micahzoltu), erik marks (@rekmarks), "eip-2700: javascript provider event emitter," ethereum improvement proposals, no. 2700, june 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2700. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. slasher: a punitive proof-of-stake algorithm | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search slasher: a punitive proof-of-stake algorithm posted by vitalik buterin on january 15, 2014 research & development the purpose of this post is not to say that ethereum will be using slasher in place of dagger as its main mining function. rather, slasher is a useful construct to have in our war chest in case proof of stake mining becomes substantially more popular or a compelling reason is provided to switch. slasher may also benefit other cryptocurrencies that wish to exist independently of ethereum. special thanks to tacotime for some inspiration, and for jack walker for improvement suggestions. proof of stake mining has for a long time been a large area of interest to the cryptocurrency community. the first proof-of-stake based coin, ppcoin, was releasd by sunny king in 2012, and has consistently remained among the top five alternative currencies by monetary base since then. and for good reason; proof of stake has a number of advantages over proof of work as a mining method. first of all, proof of stake is much more environmentally friendly; while proof of work requires miners to effectively burn computational power on useless calculations to secure the network, proof of stake effectively simulates the burning, so no real-world energy or resources are ever actually wasted. second, there are centralization concerns. with proof of work, mining has been essentially dominated by specialized hardware (“application-specific integrated circuits” / asics), and there is a large risk that a single large player such as intel or a major bank will take over and de-facto monopolize the market. memory-hard mining algorithms like scrypt and now dagger mitigate this to a large extent, but even still not perfectly. once again, proof of stake, if it can be made to work, is essentially a perfect solution. however, proof of stake, as implemented in nearly every currency so far, has one fundamental flaw: as one prominent bitcoin developer put it, “there’s nothing at stake”. the meaning of the statement becomes clear when we attempt to analyze what exactly is going on in the event of an attempted 51% attack, the situation that any kind of proof-of-work like mechanism is intended to prevent. in a 51% attack, an attacker a sends a transaction from a to b, waits for the transaction to be confirmed in block k1 (with parent k), collects a product from b, and then immediately creates another block k2 on top of k – with a transaction sending the same bitcoins but this time from a to a. at that point, there are two blockchains, one from block k1 and another from block k2. if b can add blocks on top of k2 faster than the entire legitimate network can create blocks on top of k1, the k2 blockchain will win – and it will be as if the payment from a to b had never happened. the point of proof of work is to make it take a certain amount of computational power to create a block, so that in order for k2 to outrace k1 b would have to have more computational power than the entire legitimate network combined. in the case of proof of stake, it doesn’t take computational power to create a work – instead, it takes money. in ppcoin, every “coin” has a chance per second of becoming the lucky coin that has the right to create a new valid block, so the more coins you have the faster you can create new blocks in the long run. thus, a successful 51% attack, in theory, requires not having more computing power than the legitimate network, but more money than the legitimate network. but here we see the difference between proof of work and proof of stake: in proof of work, a miner can only mine on one fork at a time, so the legitimate network will support the legitimate blockchain and not an attacker’s blockchain. in proof of stake, however, as soon as a fork happens miners will have money in both forks at the same time, and so miners will be able to mine on both forks. in fact, if there is even the slightest chance that the attack will succeed, miners have the incentive to mine on both. if a miner has a large number of coins, the miner will want to oppose attacks to preserve the value of their own coins; in an ecosystem with small miners, however, network security potentially falls apart in a classic public goods problem as no single miner has substantial impact on the result and so every miner will act purely “selfishly”. the solution some have theorized that the above argument is a deathblow to all proof of stake, at least without a proof of work component assisting it. and in a context where every chain is only aware of itself, this is indeed provably true. however, there is actually one clever way to get around the issue, and one which has so far been underexplored: make the chain aware of other chains. then, if a miner is caught mining on two chains at the same time, that miner can be penalized. however, it is not at all obvious how to do this with a ppcoin-like design. the reason is this: mining is a random process. that is to say, a miner with 0.1% of the stake has a 0.1% chance of mining a valid block on block k1, and a 0.1% chance of mining a valid block on block k2, but only a 0.0001% chance of mining a valid block on both. and in that case, the miner can simply hold back the second block – because mining is probabilistic, the miner can still gain 99.9% of the benefit of mining on the second chain. the following proposal, however, outlines an algorithm, which we are calling slasher to express its harshly punitive nature, for avoiding this proposal. the design description given here uses address balances for clarity, but can easily be used to work with “unspent transaction outputs”, or any other similar abstraction that other currencies may use. blocks are mined with proof of work. however, we make one modification. when creating a block k, a miner must include the value h(n) for some random n generated by the miner. the miner must claim the reward by releasing a transaction uncovering n between block k+100 and k+900. the proof of work reward is very low, ideally encouraging energy usage equal to about 1% of that of bitcoin. the target block time is 30 seconds. suppose the total money supply is m, and n[i] is the n value at block i. at block k+1000, an address a with balance b gains a “signing privilege” if sha256(n[k] + n[k+1] + ... + n[k+99] + a) < 2^256 * 64 * b / m. essentially, an address has a chance of gaining a signing privilege proportional to the amount of money that it has, and on average 64 signing privileges will be assigned each block. at block k+2000, miners with signing privileges from block k have the opportunity to sign the block. the number of signatures is what determines the total length of one blockchain versus another. a signature awards the signer a reward that is substantially larger than the proof of work reward, and this reward will unlock by block k+3000. suppose that a user detects two signatures made by address a on two distinct blocks with height k+2000. that node can then publish a transaction containing those two signatures, and if that transaction is included before block k+3000 it destroys the reward for that signature and sends 33% to the user that ratted the cheater out. the key to this design is how the signing privileges are distributed: instead of the signing privilege being randomly based on the previous block, the signing privilege is based on the block two thousand blocks ago. thus, in the event of a fork, a miner that gets lucky in one chain will also get lucky in the other, completely eliminating the probabilistic dual-mining attack that is possible with ppcoin. another way of looking at it is that because slasher uses proof-of-stake-2000-blocks-ago instead of proof-of-stake now, and forks will almost certainly not last 2000 blocks, there is only one currency supply to mine with, so there is indeed “something at stake”. the penalty of block reward loss ensures that every node will take care to sign only one block at each block number. the use of 100 pre-committed random numbers is an idea taken from provably fair gambling protocols; the idea is that powerful miners have no way of attempting to create many blocks and publishing only those that assign their own stake a signing privilege, since they do not know what any of the other random data used to determine the stakeholder is when they create their blocks. the system is not purely proof-of-stake; some minimal proof-of-work will be required to maintain a time interval between blocks. however, a 51% attack on the proof of work would be essentially inconsequential, as proof of stake signing is the sole deciding factor in which blockchain wins. furthermore, the energy usage from proof of work can be made to be 95-99% lower, resolving the environmental concern with proof of work. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-161: state trie clearing (invariant-preserving alternative) ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-161: state trie clearing (invariant-preserving alternative) authors gavin wood (@gavofyork) created 2016-10-24 table of contents hard fork parameters specification rationale addendum (2017-08-15) references hard fork spurious dragon parameters fork_blknum: 2,675,000 chain_id: 1 (mainnet) specification a. account creation transactions and the create operation shall, prior to the execution of the initialisation code, increment the nonce over and above its normal starting value by one (for normal networks, this will be simply 1, however test-nets with non-zero default starting nonces will be different). b. whereas call and suicide would charge 25,000 gas when the destination is non-existent, now the charge shall only be levied if the operation transfers more than zero value and the destination account is dead. c. no account may change state from non-existent to existent-but-_empty_. if an operation would do this, the account shall instead remain non-existent. d. at the end of the transaction, any account touched by the execution of that transaction which is now empty shall instead become non-existent (i.e. deleted). where: an account is considered to be touched when it is involved in any potentially state-changing operation. this includes, but is not limited to, being the recipient of a transfer of zero value. an account is considered empty when it has no code and zero nonce and zero balance. an account is considered dead when either it is non-existent or it is empty. at the end of the transaction is immediately following the execution of the suicide list, prior to the determination of the state trie root for receipt population. an account changes state when: it is the target or refund of a suicide operation for zero or more value; it is the source or destination of a call operation or message-call transaction transferring zero or more value; it is the source or creation of a create operation or contract-creation transaction endowing zero or more value; as the block author (“miner”) it is the recipient of block-rewards or transaction-fees of zero or more value. notes in the present ethereum protocol, it should be noted that very few state changes can ultimately result in accounts that are empty following the execution of the transaction. in fact there are only four contexts that current implementations need track: an empty account has zero value transferred to it through call; an empty account has zero value transferred to it through suicide; an empty account has zero value transferred to it through a message-call transaction; an empty account has zero value transferred to it through a zero-gas-price fees transfer. rationale same as #158 except that several edge cases are avoided since we do not break invariants: that an account can go from having code and storage to not having code or storage mid-way through the execution of a transaction; [corrected] that a newly created account cannot be deleted prior to being deployed. create avoids zero in the nonce to avoid any suggestion of the oddity of created accounts being reaped half-way through their creation. addendum (2017-08-15) on 2016-11-24, a consensus bug occurred due to two implementations having different behavior in the case of state reverts.[3] the specification was amended to clarify that empty account deletions are reverted when the state is reverted. references eip-158 issue and discussion: https://github.com/ethereum/eips/issues/158 eip-161 issue and discussion: https://github.com/ethereum/eips/issues/161 https://blog.ethereum.org/2016/11/25/security-alert-11242016-consensus-bug-geth-v1-4-19-v1-5-2/ details: geth was failing to revert empty account deletions when the transaction causing the deletions of empty accounts ended with an an out-of-gas exception. an additional issue was found in parity, where the parity client incorrectly failed to revert empty account deletions in a more limited set of contexts involving out-of-gas calls to precompiled contracts; the new geth behavior matches parity’s, and empty accounts will cease to be a source of concern in general in about one week once the state clearing process finishes. citation please cite this document as: gavin wood (@gavofyork), "eip-161: state trie clearing (invariant-preserving alternative)," ethereum improvement proposals, no. 161, october 2016. [online serial]. available: https://eips.ethereum.org/eips/eip-161. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6: renaming suicide opcode ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: interface eip-6: renaming suicide opcode authors hudson jameson created 2015-11-22 table of contents abstract motivation implementation abstract the solution proposed in this eip is to change the name of the suicide opcode in ethereum programming languages with selfdestruct. motivation mental health is a very real issue for many people and small notions can make a difference. those dealing with loss or depression would benefit from not seeing the word suicide in our programming languages. by some estimates, 350 million people worldwide suffer from depression. the semantics of ethereum’s programming languages need to be reviewed often if we wish to grow our ecosystem to all types of developers. an ethereum security audit commissioned by devolution, gmbh and performed by least authority recommended the following: replace the instruction name “suicide” with a less connotative word like “self-destruct”, “destroy”, “terminate”, or “close”, especially since that is a term describing the natural conclusion of a contract. the primary reason for us to change the term suicide is to show that people matter more than code and ethereum is a mature enough of a project to recognize the need for a change. suicide is a heavy subject and we should make every effort possible to not affect those in our development community who suffer from depression or who have recently lost someone to suicide. ethereum is a young platform and it will cause less headaches if we implement this change early on in its life. implementation selfdestruct is added as an alias of suicide opcode (rather than replacing it). https://github.com/ethereum/solidity/commit/a8736b7b271dac117f15164cf4d2dfabcdd2c6fd https://github.com/ethereum/serpent/commit/1106c3bdc8f1bd9ded58a452681788ff2e03ee7c citation please cite this document as: hudson jameson , "eip-6: renaming suicide opcode," ethereum improvement proposals, no. 6, november 2015. [online serial]. available: https://eips.ethereum.org/eips/eip-6. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-1056: ethereum lightweight identity ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1056: ethereum lightweight identity authors pelle braendgaard , joel torstensson created 2018-05-03 discussion link https://github.com/ethereum/eips/issues/1056 table of contents simple summary abstract motivation definitions specification identity ownership delegate management attribute management events efficient lookup of events through linked identity events building a did document for an identity rationale backwards compatibility implementation deployment copyright simple summary a registry for key and attribute management of lightweight blockchain identities. abstract this erc describes a standard for creating and updating identities with a limited use of blockchain resources. an identity can have an unlimited number of delegates and attributes associated with it. identity creation is as simple as creating a regular key pair ethereum account, which means that it’s free (no gas costs) and all ethereum accounts are valid identities. furthermore this erc is fully did compliant. motivation as we have been developing identity systems for the last couple of years at uport it has become apparent that the cost of identity creation is a large issue. the previous identity proposal erc-725 faces this exact issue. our requirements when creating this erc is that identity creation should be free, and should be possible to do in an offline environment (e.g. refugee scenario). however it must also be possible to rotate keys without changing the primary identifier of the identity. the identity system should be fit to use off-chain as well as on-chain. definitions identifier: a piece of data that uniquely identifies the identity, an ethereum address delegate: an address that is delegated for a specific time to perform some sort of function on behalf of an identity delegatetype: the type of a delegate, is determined by a protocol or application higher up examples: did-jwt raiden attribute: a piece of data associated with the identity specification this erc specifies a contract called ethereumdidregistry that is deployed once and can then be commonly used by everyone. identity ownership by default an identity is owned by itself, meaning whoever controls the ethereum account with that address. the owner can be updated to a new key pair account or to a multisig account etc. identityowner returns the owner of the given identity. function identityowner(address identity) public view returns(address); changeowner sets the owner of the given identity to another ethereum account. function changeowner(address identity, address newowner) public; changeownersigned same as above but with raw signature. function changeownersigned(address identity, uint8 sigv, bytes32 sigr, bytes32 sigs, address newowner) public; delegate management delegates can be used both onand off-chain. they all have a delegatetype which can be used to specify the purpose of the delegate. validdelegate returns true if the given delegate is a delegate with type delegatetype of identity. function validdelegate(address identity, bytes32 delegatetype, address delegate) public view returns(bool); adddelegate adds a new delegate with the given type. validity indicates the number of seconds that the delegate will be valid for, after which it will no longer be a delegate of identity. function adddelegate(address identity, bytes32 delegatetype, address delegate, uint validity) public; adddelegatesigned same as above but with raw signature. function adddelegatesigned(address identity, uint8 sigv, bytes32 sigr, bytes32 sigs, bytes32 delegatetype, address delegate, uint validity) public; revokedelegate revokes the given delegate for the given identity. function revokedelegate(address identity, bytes32 delegatetype, address delegate) public; revokedelegatesigned same as above but with raw signature. function revokedelegatesigned(address identity, uint8 sigv, bytes32 sigr, bytes32 sigs, bytes32 delegatetype, address delegate) public; attribute management attributes contain simple data about the identity. they can be managed only by the owner of the identity. setattribute sets an attribute with the given name and value, valid for validity seconds. function setattribute(address identity, bytes32 name, bytes value, uint validity) public; setattributesigned same as above but with raw signature. function setattributesigned(address identity, uint8 sigv, bytes32 sigr, bytes32 sigs, bytes32 name, bytes value, uint validity) public; revokeattrubte revokes an attribute. function revokeattribute(address identity, bytes32 name, bytes value) public; revokeattributesigned same as above but with raw signature. function revokeattributesigned(address identity, uint8 sigv, bytes32 sigr, bytes32 sigs, bytes32 name, bytes value) public; events didownerchanged must be triggered when changeowner or changeownersigned was successfully called. event didownerchanged( address indexed identity, address owner, uint previouschange ); diddelegatechanged must be triggered when a change to a delegate was successfully made. event diddelegatechanged( address indexed identity, bytes32 delegatetype, address delegate, uint validto, uint previouschange ); didattrituechanged must be triggered when a change to an attribute was successfully made. event didattributechanged( address indexed identity, bytes32 name, bytes value, uint validto, uint previouschange ); efficient lookup of events through linked identity events contract events are a useful feature for storing data from smart contracts exclusively for off-chain use. unfortunately current ethereum implementations provide a very inefficient lookup mechanism. by using linked events that always link to the previous block with a change for the identity, we can solve this problem with much improved performance. each identity has its previously changed block stored in the changed mapping. lookup previouschange block for identity lookup all events for given identity address using web3, but only for the previouschange block do something with event find previouschange from the event and repeat example code: const history = [] previouschange = await didreg.changed(identity) while (previouschange) { const filter = await didreg.allevents({topics: [identity], fromblock: previouschange, toblock: previouschange}) const events = await getlogs(filter) previouschange = undefined for (let event of events) { history.unshift(event) previouschange = event.args.previouschange } } building a did document for an identity the primary owner key should be looked up using identityowner(identity). this should be the first of the publickeys listed. iterate through the diddelegatechanged events to build a list of additional keys and authentication sections as needed. the list of delegatetypes to include is still to be determined. iterate through didattributechanged events for service entries, encryption public keys and other public names. the attribute names are still to be determined. rationale for on-chain interactions ethereum has a built in account abstraction that can be used regardless of whether the account is a smart contract or a key pair. any transaction has a msg.sender as the verified send of the transaction. since each ethereum transaction has to be funded, there is a growing trend of on-chain transactions that are authenticated via an externally created signature and not by the actual transaction originator. this allows 3rd party funding services or receiver pays without any fundamental changes to the underlying ethereum architecture. these kinds of transactions have to be signed by an actual key pair and thus can not be used to represent smart contract based ethereum accounts. we propose a way of a smart contract or regular key pair delegating signing for various purposes to externally managed key pairs. this allows a smart contract to be represented both on-chain as well as off-chain or in payment channels through temporary or permanent delegates. backwards compatibility all ethereum accounts are valid identities (and did compatible) using this standard. this means that any wallet provider that uses key pair accounts already supports the bare minimum of this standard, and can implement delegate and attribute functionality by simply using the ethr-did referenced below. as the did auth standard solidifies it also means that all of these wallets will be compatible with the did decentralized login system. implementation ethr-did-registry (ethereumdidregistry contract implementation) ethr-did-resolver (did compatible resolver) ethr-did (javascript library for using the identity) deployment the address for the ethereumdidregistry is 0xdca7ef03e98e0dc2b855be647c39abe984fcf21b on mainnet, ropsten, rinkeby and kovan. copyright copyright and related rights waived via cc0. citation please cite this document as: pelle braendgaard , joel torstensson , "erc-1056: ethereum lightweight identity [draft]," ethereum improvement proposals, no. 1056, may 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1056. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6353: charity token ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-6353: charity token extension of eip-20 token that can be partially donated to a charity project authors aubay , boca jeabby (@bjeabby1507), el mershati laith (@lth-elm), kemp elia (@eliakemp) created 2022-05-13 discussion link https://ethereum-magicians.org/t/erc20-charity-token/12617 requires eip-20 table of contents abstract motivation specification functions rationale backwards compatibility test cases reference implementation security considerations copyright abstract an extension to eip-20 that can automatically send an additional percentage of each transfer to a third party, and that provides an interface for retrieving this information. this can allow token owners to make donations to a charity with every transfer. this can also be used to allow automated savings programs. motivation there are charity organizations with addresses on-chain, and there are token holders who want to make automated donations. having a standardized way of collecting and managing these donations helps users and user interface developers. users can make an impact with their token and can contribute to achieving sustainable blockchain development. projects can easily retrieve charity donations addresses and rate for a given eip-20 token, token holders can compare minimum rate donation offers allowed by token contract owners. this standard provides functionality that allows token holders to donate easily. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. owner of the contract may, after review, register charity address in whitelistedrate and set globally a default rate of donation. to register the address, the rate must not be null. token holders may choose and specify a default charity address from _defaultaddress, this address should be different from the null address for the donation to be activated. the donation is a percentage-based rate model, but the calculation can be done differently. applications and individuals can implement this standard by retrieving information with charityinfo() , which specifies an assigned rate for a given address. this standard provides functionality that allows token holders to donate easily. the donation when activated is done directly in the overridden transfer, transferfrom, and approve functions. when transfer, transferfrom are called the sender’s balance is reduced by the initial amount and a donation amount is deduced. the initial transfered amount is transferred to the recipient’s balance and an additional donation amount is transfered to a third party (charity). the two transfer are done at the same time and emit two transfer events. also, if the account has an insufficient balance to cover the transfer and the donation the whole transfer would revert. // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.4; /// /// @dev required interface of an erc20 charity compliant contract. /// interface ierc20charity is ierc165 { /// the eip-165 identifier for this interface is 0x557512b6 /** * @dev emitted when `toadd` charity address is added to `whitelistedrate`. */ event addedtowhitelist (address toadd); /** * @dev emitted when `toremove` charity address is deleted from `whitelistedrate`. */ event removedfromwhitelist (address toremove); /** * @dev emitted when `_defaultaddress` charity address is modified and set to `whitelistedaddr`. */ event donnationaddresschanged (address whitelistedaddr); /** * @dev emitted when `_defaultaddress` charity address is modified and set to `whitelistedaddr` * and _donation is set to `rate`. */ event donnationaddressandratechanged (address whitelistedaddr,uint256 rate); /** * @dev emitted when `whitelistedrate` for `whitelistedaddr` is modified and set to `rate`. */ event modifiedcharityrate(address whitelistedaddr,uint256 rate); /** *@notice called with the charity address to determine if the contract whitelisted the address *and if it is the rate assigned. *@param addr the charity address queried for donnation information. *@return whitelisted true if the contract whitelisted the address to receive donnation *@return defaultrate the rate defined by the contract owner by default , the minimum rate allowed different from 0 */ function charityinfo( address addr ) external view returns ( bool whitelisted, uint256 defaultrate ); /** *@notice add address to whitelist and set rate to the default rate. * @dev requirements: * * `toadd` cannot be the zero address. * * @param toadd the address to whitelist. */ function addtowhitelist(address toadd) external; /** *@notice remove the address from the whitelist and set rate to the default rate. * @dev requirements: * * `toremove` cannot be the zero address. * * @param toremove the address to remove from whitelist. */ function deletefromwhitelist(address toremove) external; /** *@notice get all registered charity addresses. */ function getallwhitelistedaddresses() external ; /** *@notice display for a user the rate of the default charity address that will receive donation. */ function getrate() external view returns (uint256); /** *@notice set personlised rate for charity address in {whitelistedrate}. * @dev requirements: * * `whitelistedaddr` cannot be the zero address. * `rate` cannot be inferior to the default rate. * * @param whitelistedaddr the address to set as default. * @param rate the personalised rate for donation. */ function setspecificrate(address whitelistedaddr , uint256 rate) external; /** *@notice set for a user a default charity address that will receive donation. * the default rate specified in {whitelistedrate} will be applied. * @dev requirements: * * `whitelistedaddr` cannot be the zero address. * * @param whitelistedaddr the address to set as default. */ function setspecificdefaultaddress(address whitelistedaddr) external; /** *@notice set for a user a default charity address that will receive donation. * the rate is specified by the user. * @dev requirements: * * `whitelistedaddr` cannot be the zero address. * `rate` cannot be less than to the default rate * or to the rate specified by the owner of this contract in {whitelistedrate}. * * @param whitelistedaddr the address to set as default. * @param rate the personalised rate for donation. */ function setspecificdefaultaddressandrate(address whitelistedaddr , uint256 rate) external; /** *@notice display for a user the default charity address that will receive donation. * the default rate specified in {whitelistedrate} will be applied. */ function specificdefaultaddress() external view returns ( address defaultaddress ); /** *@notice delete the default address and so deactivate donnations . */ function deletedefaultaddress() external; } functions addtowhitelist add address to whitelist and set the rate to the default rate. parameter description toadd the address to the whitelist. deletefromwhitelist remove the address from the whitelist and set rate to the default rate. parameter description toremove the address to remove from whitelist. getallwhitelistedaddresses get all registered charity addresses. getrate display for a user the rate of the default charity address that will receive donation. setspecificrate set personalized rate for charity address in {whitelistedrate}. parameter description whitelistedaddr the address to set as default. rate the personalised rate for donation. setspecificdefaultaddress set for a user a default charity address that will receive donations. the default rate specified in {whitelistedrate} will be applied. parameter description whitelistedaddr the address to set as default. setspecificdefaultaddressandrate set for a user a default charity address that will receive donations. the rate is specified by the user. parameter description whitelistedaddr the address to set as default. rate the personalized rate for donation. specificdefaultaddress display for a user the default charity address that will receive donations. the default rate specified in {whitelistedrate} will be applied. deletedefaultaddress delete the default address and so deactivate donations. charityinfo called with the charity address to determine if the contract whitelisted the address and if it is, the rate assigned. parameter description addr the charity address queried for donnation information. rationale this eip chooses to whitelist charity addresses by using an array and keeping track of the “active” status with a mapping whitelistedrate to allow multiple choice of recipient and for transparence. the donation address can also be a single address chosen by the owner of the contract and modified by period. if the sender balance is insuficent i.e total amount of token (initial transfer + donation) is insuficent the transfer would revert. donation are done in the transfer function to simplify the usage and to not add an additional function, but the implementation could be donne differently, and for exemple allow a transfer to go through without the donation amount when donation is activated. the token implementer can also choose to store the donation in the contract or in another one and add a withdrawal or claimable function, so the charity can claim the allocated amount of token themselves, the additional transfer will be triggered by the charity and not the token holder. also, donations amount are calculated here as a percentage of the amount of token transfered to allow different case scenario, but the token implementer can decide to opt for another approach instead like rounding up the transaction value. backwards compatibility this implementation is an extension of the functionality of eip-20, it introduces new functionality retaining the core interfaces and functionality of the eip-20 standard. there is a small backwards compatibility issue, indeed if an account has insufficient balance, it’s possible for the transfer to fail. test cases tests can be found in charity.js. reference implementation the reference implementation of the standard can be found under contracts/ folder. security considerations there are no additional security considerations compared to eip-20. copyright copyright and related rights waived via cc0. citation please cite this document as: aubay , boca jeabby (@bjeabby1507), el mershati laith (@lth-elm), kemp elia (@eliakemp), "erc-6353: charity token [draft]," ethereum improvement proposals, no. 6353, may 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-6353. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. capture your contributions to the hedera ecosystem in the… | hedera hedera network services token service mint and configure tokens and accounts. consensus service verifiable timestamps and ordering of events. smart contracts run solidity smart contracts. hbar the hedera network's native cryptocurrency. insights how it works learn about hedera from end to end. explorers view live and historical data on hedera. dashboards analyze network activity and metrics. network nodes understand networks and node types. devs start building get started learn core concepts and build the future. documentation review the api and build using your favorite language. developer resources integrations plugins and microservices for hedera. fee estimator understand and estimate transaction costs. open source hedera is committed to open, transparent code. learning center learn about web3 and blockchain technologies. grants grants & accelerators for your project. bounties find bugs. submit a report. earn rewards. ecosystem ecosystem hedera ecosystem applications, developer tools, network explorers, and more. nft ecosystem metrics analyze on-chain and market nft ecosystem metrics. categories web3 applications connect into the innovative startups decentralizing the web on hedera. enterprise applications learn about the fortune 500 companies decentralizing the web on hedera. wallets & custodians create a hedera account to manage hbar, fungible tokens, and nfts. network explorers hedera mainnet and testnet graphical network explorers. developer tooling third-party apis, integrations, and plugins to build apps on hedera. grants & accelerators boost your project with support from the hedera ecosystem. partner program explore our partners to bring your vision into reality. hedera council over 30 highly diversified organizations govern hedera. use cases hedera solutions asset tokenization studio open source toolkit for tokenizing assets securely. stablecoin studio all-in-one toolkit for stablecoin solutions. hedera guardian auditable carbon markets and traceability. functional use cases data integrity & ai reliable, secure, and ethically governed insights. sustainability enabling fair carbon markets with trust. real-world asset tokenization seamless tokenization of real-world assets and digital at scale. consumer engagement & loyalty mint, distribute, and redeem loyalty rewards. decentralized identity maintain the lifecycle of credentials. decentralized logs scalable, real-time timestamped events. defi dapps built for the next-generation of finance. nfts low, fixed fees. immutable royalties. payments scalable, real-time, and affordable crypto-payments. hbar overview learn about hedera's token, hbar. treasury management hedera’s report of the hbar supply. governance decentralized governance hedera council see the world's leading organizations that own hedera. about meet hedera's board of directors and team. journey watch hedera's journey to build an empowered digital future for all. transparent governance public policy hedera's mission is to inform policy and regulation that impact the industry. meeting minutes immutably recorded on hedera. roadmap follow hedera's roadmap in its journey to build the future. resources company what's new partners papers careers media blog technical press podcast community events meetups store brand navigation quickstart capture your contributions to the hedera ecosystem in the electric capital developer report technical oct 22, 2024 by ed marquez head of developer relations the electric capital developer report is a valuable resource for tracking developer activity across blockchain ecosystems, including hedera. featuring your work in this report increases visibility for your project, draws more developers to the hedera ecosystem, and shows the strength and diversity of our community. here’s how your project can be included in the electric capital developer report: 1. submit a pull request (pr) follow the steps below to add your sub-ecosystem, organization, or individual repositories to the hedera section of the electric capital report: i. fork the repository: visit the electric capital crypto-ecosystems github repo. in the top-right corner, click "fork" to create a copy in your github account. ii. navigate to the hedera file: open the /data/ecosystems/h/hedera.toml file in your forked repo. iii. add your project: to add a sub-ecosystem (e.g., a large organization with multiple repositories), include it under the sub_ecosystems or github_organizations section to add an individual repository, include the repository url and any relevant tags in the # repositories section of the .toml file. iv. submit the pr: once your changes are made, navigate to your forked repo and click "pull request" to submit your updates for review. 2. use the airtable submission form if submitting a pr feels complex, you can submit your project via this airtable form, and the electric capital team will handle the rest. 3. add "hedera" as a github topic to make your repository more discoverable within the hedera ecosystem: go to your github repository’s "about" section. click the gear icon (⚙️). under "topics," type hedera and select it from the dropdown. save your changes. conclusion adding your project to the electric capital developer report is a great way to gain visibility for your work and tell the world about the innovation happening in the hedera ecosystem. your involvement helps highlight the diversity and strength of our community, attracting more developers, collaborators, and attention to the network. whether you submit a pull request, tag your repo with "hedera," or use the airtable form, you’re playing a key role in driving the growth of our ecosystem. take a moment to get your project included—let’s keep building a stronger, more vibrant community together! share this back to blog what is grpc, grpc-web, and proxies? ed marquez pragmatic blockchain design patterns – integrating blockchain into business processes michiel mulders zero cost ethereumtransaction on success: hedera's new fee model for relay operators oliver thorn hedera adopts chainlink standard for cross-chain interoperability to accelerate ecosystem adoption hedera team hedera developer highlights march 2025 michiel mulders hedera release cycle overview ed marquez view all posts sign up for the newsletter connect with us transparency open source audits & standards sustainability commitment carbon offsets governance hedera council public policy treasury management meeting minutes llc agreement node requirements community events meetups hbar telegram developer discord twitter community support faq network status developer discord stackoverflow brand brand guidelines built on hedera logo hedera store about team partners journey roadmap careers contact general inquiry public relations © 2018-2025 hedera hashgraph, llc. all trademarks and company names are the property of their respective owners. all rights in the deutsche telekom mark are protected by deutsche telekom ag. all rights reserved. hedera uses the third party marks with permission. terms of use | privacy policy eip-1380: reduced gas cost for call to self ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-1380: reduced gas cost for call to self authors alex beregszaszi (@axic), jacques wagener (@jacqueswww) created 2018-08-31 discussion link https://ethereum-magicians.org/t/eip-1380-reduced-gas-cost-for-call-to-self/1242 requires eip-150 table of contents abstract motivation specification rationale backwards compatibility test cases implementation copyright abstract reduce the gas cost for call instructions, when the goal is to run a new instance of the currently loaded contract. motivation the current gas cost of 700 for all call types (call, delegatecall, callcode and staticcall) does not take into account that a call to a contract itself does not need to perform additional i/o operations, because the current contract code has already been loaded into memory. reducing the call-to-self gas cost would greatly benefit smart contract languages, such as solidity and vyper, who would then be able to utilise call instead of jump opcodes for internal function calls. while languages can already utilise call for internal function calls, they are discouraged to do so due to the gas costs associated with it. using jump comes at a considerable cost in complexity to the implementation of a smart contract language and/or compiler. the context (including stack and memory) must be swapped in and out of the calling functions context. a desired feature is having pure functions, which do not modify the state of memory, and realising them through jump requires a bigger effort from the compiler as opposed to being able to use calls. using call-to-self provides the guarantee that when making an internal call the function can rely on a clear reset state of memory or context, benefiting both contract writers and contract consumers against potentially undetetected edge cases were memory could poison the context of the internal function. because of the jump usage for internal functions a smart contract languages are also at risk of reaching the stack depth limit considerbly faster, if nested function calls with many in and/or outputs are required. reducing the gas cost, and thereby incentivising of using call-to-self instead of jumps for the internal function implementation will also benefit static analyzers and tracers. specification if block.number >= fork_blknum, then decrease the cost of call, delegatecall, callcode and staticcall from 700 to 40, if and only if, the destination address of the call equals to the address of the caller. rationale eip150 has increased the cost of these instructions from 40 to 700 to more fairly charge for loading new contracts from disk, e.g. to reflect the i/o charge more closely. by assuming that 660 is the cost of loading a contract from disk, one can assume that the original 40 gas is a fair cost of creating a new vm instance of an already loaded contract code. backwards compatibility this should pose no risk to backwards compatibility. currently existing contracts should not notice the difference, just see cheaper execution. with eip150 contract (and language) developers had a lesson that relying on strict gas costs is not feasible as costs may change. the impact of this eip is even less that of eip150 because the costs are changing downwards and not upwards. test cases tba implementation tba copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), jacques wagener (@jacqueswww), "eip-1380: reduced gas cost for call to self [draft]," ethereum improvement proposals, no. 1380, august 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1380. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-7069: revamped call instructions ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: core eip-7069: revamped call instructions introduce call2, delegatecall2 and staticcall2 with simplified semantics authors alex beregszaszi (@axic), paweł bylica (@chfast), danno ferrin (@shemnon), andrei maiboroda (@gumb0), charles cooper (@charles-cooper) created 2023-05-05 discussion link https://ethereum-magicians.org/t/eip-revamped-call-instructions/14432 requires eip-150, eip-211, eip-214, eip-2929 table of contents abstract motivation specification rationale removing gas selectability stipend and 63/64th rule output buffers status codes parameter order opcode encoding callcode backwards compatibility security considerations copyright abstract introduce three new call instructions, call2, delegatecall2 and staticcall2, with simplified semantics. introduce another instruction, returndataload for loading a word from return data into stack. the existing call instructions remain unchanged. the new instructions do not allow specifying a gas limit, but rather rely on the “63/64th rule” (eip-150) to limit gas. an important improvement is the rules around the “stipend” are simplified, and callers do not need to perform special calculation whether the value is sent or not. furthermore, the obsolete functionality of specifying output buffer address is removed in favor of using returndatacopy instead. for cases which would previously *call output into a buffer and then mload from the buffer, returndataload is provided instead. lastly, instead of returning a boolean for execution status, an extensible list of status codes is returned: 0 for success, 1 for revert, 2 for failure. we expect most new contracts to rely on the new instructions (for simplicity and in order to save gas), and some specific contracts where gas limiting is required to keep using the old instructions (e.g. erc-4337). motivation observability of gas has been a problem for very long. the system of gas has been (and likely must be) flexible in adapting to changes to both how ethereum is used as well as changes in underlying hardware. unfortunately, in many cases compromises or workarounds had to be made to avoid affecting call instructions negatively, mostly due to the complex semantics and expectations of them. this change aims to remove gas observability from the new instructions and opening the door for new classes of contracts that are not affected by repricings. furthermore, once the evm object format (eof) is introduced, the legacy call instructions can be rejected within eof contracts, making sure they are mostly unaffected by changes in gas fees. because these operations are required for removing gas observability they will be required for eof in lieu of the existing instructions. it is important to note that starting solidity 0.4.21, the compiler already passes all remaining gas to calls (using call(gas(), ...), unless the developer uses the explicit override ({gas: ...}) in the language. this suggests most contracts don’t rely on controlling gas. besides the above, this change introduces a convenience feature of returning more detailed status codes: success (0), revert (1), failure (2). this moves from the boolean option to codes, which are extensible in the future. lastly, the introduction of the returndata* instructions (eip-211) has obsoleted the output parameters of calls, in a large number of cases rendering them unused. using the output buffers have caused “bugs” in the past: in the case of erc-20, conflicting implementations caused a lot of trouble, where some would return something, while others would not. with relying on returndata* instructions this is implicitly clarified. this proposal also adds the “missing” returndataload instruction to round out returndata buffer access instructions. specification name value comment warm_storage_read_cost 100 from eip-2929 cold_account_access 2600 from eip-2929 call_value_cost 9000 account_creation_cost 25000 min_retained_gas 5000 min_callee_gas 2300 we introduce four new instructions: call2 (0xf8) with arguments (target_address, input_offset, input_size, value) delegatecall2 (0xf9) with arguments (target_address, input_offset, input_size) staticcall2 (0xfb) with arguments (target_address, input_offset, input_size) returndataload (0xf7) with argument offset execution semantics of *call2: charge warm_storage_read_cost (100) gas. pop required arguments from stack, fail with error on stack underflow. if value is non-zero: 3a. fail with error if the current frame is in static-mode. 3b. fail with error if the balance of the current account is less than value. 3c. charge call_value_cost gas. peform (and charge for) memory expansion using [input_offset, input_size]. if target_address is not in the warm_account_list, charge cold_account_access warm_storage_read_cost (2500) gas. if target_address is not in the state and the call configuration would result in account creation, charge account_creation_cost (25000) gas. the only such case in this eip is if value is non-zero. calculate the gas available to callee as caller’s remaining gas reduced by max(ceil(gas/64), min_retained_gas) (min_retained_gas is 5000). fail with error if the gas available to callee at this point is less than min_callee_gas (2300). perform the call with the available gas and configuration. push a status code on the stack: 11a. 0 if the call was successful. 11b. 1 if the call has reverted. 11c. 2 if the call has failed. gas not used by the callee is returned to the caller. execution semantics of returndataload: charge g_verylow (3) gas pop 1 item from the stack, to be referred to as offset if offset + 32 > len(returndata buffer), halt with exceptional failure. push 1 item onto the stack, the 32-byte word read from the returndata buffer starting at offset. rationale removing gas selectability one major change from the original call series of instructions is that the caller has no control over the amount of gas passed in as part of the call. the number of cases where such a feature is essential are probably better served by direct protocol integration. removing gas selectability also introduces a valuable property that future revisions to the gas schedule will benefit from: you can always overcome out of gas (oog) errors by sending more gas as part of the transaction (subject to the block gas limit). previously when raising storage costs (eip-1884) some contracts that sent only a limited amount of gas to their calls were broken by the new costing. hence some contracts had a gas ceiling they were sending to their next call, permanently limiting the amount of gas they could spend. no amount of extra gas could fix the issue as the call would limit the amount sent. the notion of a stipend floor is retained in this spec. this floor can be changed independent of the smart contracts and still preserve the feature that oog halts can be fixed by sending more gas as part of the transaction. stipend and 63/64th rule the purpose of the stipend is to have enough gas to emit logs (i.e. perform non-state-changing operations) when a “contract wallet” is called. the stipend is only added when the target has code and the call value is non-zero. the 63/64th rule has multiple purposes: a. to limit call depth, b. to ensure the caller has gas left to make state changes after a callee returns. additionally there is a call depth counter, and calls fail if the depth would exceed 1024. before the 63/64th rule was introduced, it was required to calculate available gas semi-accurately on caller side. solidity has a complicated ruleset where it tries to estimate how much it will cost on the caller side to perform the call itself, in order to set a reasonable gas value. we have changed the ruleset: removed the call depth check. use the 63/64th rule, but 2a. ensure that at least 5000 gas is retained prior to executing the callee, 2b. ensure that at least 2300 gas is available to the callee. output buffers the functionality of specifying output buffer address is removed, because it is added complexity and in a large number of cases implementers prefer to use returndatacopy instead. even if they rely on the output buffer (like in the case of vyper), they would still check the length with returndatasize. in solidity one exception is the case when the expected return size is known (i.e. non-dynamic return values), in this case solidity still uses the output buffer. for these cases, returndataload is introduced, which simplifies the workflow of copying returndata into a (known) output buffer and using mload from there; instead, returndataload can be used directly. status codes current call instructions return a boolean value to signal success: 0 means failure, 1 means success. the solidity compiler assumed this value is a boolean and thus uses the value as branch condition to status (if iszero(status) { /* failure */ }). this prevents us from introducing new status codes without breaking existing contracts. at the time of the design of eip-211 the idea of return a specific code for revert was discussed, but ultimately abandoned for the above reason. we change the value from boolean to a status code, where 0 signals success and thus it will be possible to introduce more non-success codes in the future, if desired. parameter order the order of parameters has been changed to move the value field to be the last. this allows the instructions to have identical encoding with the exception of the last parameter, and simplifies evm and compiler implementations slightly. opcode encoding instead of introducing three new *call2 opcodes we have discussed a version with an immediate configuration byte (flags). there are two main disadvantages to this: some combination of flags may not be useful/be invalid, and this increases the testing/implementation surface. the instruction could take variable number of stack items (i.e. value for call2) would be a brand new concept no other instruction has. it is also useful to have these as new opcodes instead of modifying the exiting call series inside of eof. this creates an “escape hatch” in case gas observability needs to be restored to eof contracts. this is done by adding the gas and original call series opcodes to the valid eof opcode list. callcode since callcode is deprecated, we do not introduce a counterpart here. backwards compatibility no existing instructions are changed and so we do not think any backwards compatibility issues can occur. security considerations it is expected that the attack surface will not grow. all of these operations can be modeled by existing operations with fixed gas (all available) and output range (zero length at zero memory). when implemented in eof (where the gas opcode and the original call operations are removed) existing out of gas attacks will be slightly more difficult, but not entirely prevented. transactions can still pass in arbitrary gas values and clever contract construction can still result in specific gas values being passed to specific calls. it is expected the same surface will remain in eof, but the ease of explotation will be reduced. copyright copyright and related rights waived via cc0. citation please cite this document as: alex beregszaszi (@axic), paweł bylica (@chfast), danno ferrin (@shemnon), andrei maiboroda (@gumb0), charles cooper (@charles-cooper), "eip-7069: revamped call instructions [draft]," ethereum improvement proposals, no. 7069, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7069. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7053: interoperable digital media indexing ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-7053: interoperable digital media indexing a universal indexing method to record, discover and retrieve the history of digital media on evm-compatible blockchains. authors bofu chen (@bafu), tammy yang (@tammyyang) created 2023-05-22 table of contents abstract motivation specification content identifier commit function rationale reference implementation security considerations copyright abstract this eip proposes an interoperable indexing strategy designed to enhance the organization and retrieval of digital media information across multiple smart contracts and evm-compatible blockchains. this system enhances the traceability and verification of cross-contract and cross-chain data, facilitating a more efficient discovery of storage locations and crucial information related to media assets. the major purpose is to foster an integrated digital media environment on the blockchain. motivation given the significant role digital media files play on the internet, it’s crucial to have a robust and efficient method for indexing immutable information. existing systems encounter challenges due to the absence of a universal, interoperable identifier for digital media content. this leads to fragmentation and complications in retrieving metadata, storage information, or the provenance of specific media assets. the issues become increasingly critical as the volume of digital media continues to expand. the motivation behind this eip is to establish a standardized, decentralized, and interoperable approach to index digital media across evm-compatible networks. by integrating decentralized content identifiers (cids) and commit events, this eip puts forward a mechanism enabling unique identification and indexing of each digital media file. moreover, this system suggests a way for users to access a complete history of data associated with digital media assets, from creation to the current status. this full view enhances transparency, thereby providing users with the necessary information for future interactions with digital media. this method creates a common interface that any digital media system can use to provide a standard way of indexing and searching their content. figure 1: digital media indexing relationships and lookup this eip aims to create an interoperable indexing system to associate all data of the same digital content together (figure 1). this will make it easier for users to find and trust digital media content, and it will also make it easier for systems to share and exchange information about this digital media content. 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. content identifier content identifier in this eip is the the content address generated by passing the content of a digital media through a cryptographic hash function. before the indexing process for digital media can begin, it is required to generate unique content identifiers for each file. this identifier should the same as the content identifiers on the decentralized storage, ensuring each identifier provides access to the metadata, media information, and the content file itself. commit function to index digital media, we shall call the commit function and generate commit event: /** * @notice emitted when a new commit is made. * @param recorder the address of the account making the commit. * @param assetcid the content identifier of the asset being committed. * @param commitdata the data associated with the commit. */ event commit(address indexed recorder, string indexed assetcid, string commitdata); /** * @notice registers a commit for an asset. * emits a commit event and records the block number of the commit in the recordlogs mapping for the provided assetcid. * @dev emits a commit event and logs the block number of the commit event. * @param assetcid the content identifier of the asset being committed. * @param commitdata the data associated with the commit. * @return the block number at which the commit was made. */ function commit(string memory assetcid, string memory commitdata) public returns (uint256 blocknumber); rationale the design decisions in this eip prioritize the effectiveness and efficiency of the indexing method. to achieve this, decentralized content identifiers (cids) are utilized to uniquely identify digital media content across all systems. this approach offers accurate and precise searching of media, along with the following benefits: strengthened data integrity: cids serve as cryptographic hashes of the content, ensuring their uniqueness and preventing forgery. with the content in hand, obtaining the cid allows for searching relevant information associated with that content. streamlined data portability: cids enable the seamless transfer of digital media content across different systems, eliminating the need for re-encoding or reconfiguration of protocols. this promotes a more interoperable and open indexing system. for example, in cases where non-fungible tokens (nfts) are created prior to commit events, the digital media content can still be indexed by converting the file referenced by the tokenuri using the same mechanism. this conversion process ensures that the digital media content associated with nft tokens can be indexed with a consistent identification approach. reference implementation // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.4; import "@openzeppelin/contracts/utils/cryptography/ecdsa.sol"; import "@openzeppelin/contracts-upgradeable/proxy/utils/initializable.sol"; contract commitregister is initializable { using ecdsa for bytes32; mapping(string => uint[]) public commitlogs; event commit(address indexed recorder, string indexed assetcid, string commitdata); function initialize() public initializer {} function commit(string memory assetcid, string memory commitdata) public returns (uint256 blocknumber) { emit commit(msg.sender, assetcid, commitdata); commitlogs[assetcid].push(block.number); return block.number; } function getcommits(string memory assetcid) public view returns (uint[] memory) { return commitlogs[assetcid]; } } security considerations when implementing this eip, it’s essential to address several security aspects to ensure the safety and integrity of the digital media index: input validation: given that commit function accepts string parameters, it’s important to validate these inputs to avoid potential injection attacks. although such attacks are less common in smart contracts than traditional web development, caution should be exercised. data integrity: the commit function relies on cids, which are assumed to be correct and point to the right data. it’s important to note that this eip doesn’t validate the content behind the cids and the commit data, which remains a responsibility of the users or implementing applications. event listening: systems relying on listening to the commit events for changes need to be aware of potential missed events or incorrect ordering, especially during periods of network congestion or reorganizations. implementers should consider these security aspects in the context of their specific use case and deployment scenario. it is strongly recommended to perform a comprehensive security audit before deploying any implementation of this eip to a live network. copyright copyright and related rights waived via cc0. citation please cite this document as: bofu chen (@bafu), tammy yang (@tammyyang), "erc-7053: interoperable digital media indexing," ethereum improvement proposals, no. 7053, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7053. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-725: general data key/value store and execution ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-725: general data key/value store and execution an interface for a smart contract based account with attachable data key/value store authors fabian vogelsteller (@frozeman), tyler yasaka (@tyleryasaka) created 2017-10-02 discussion link https://ethereum-magicians.org/t/discussion-for-eip725/12158 requires eip-165, eip-173 table of contents abstract motivation specification ownership erc725x erc725x methods erc725x events erc725y erc725y methods erc725y events erc725y data keys rationale backwards compatibility reference implementation security considerations solidity interfaces copyright abstract the following describes two standards that allow for a generic data storage in a smart contract and a generic execution through a smart contract. these can be used separately or in conjunction and can serve as building blocks for smart contract accounts, upgradable metadata, and other means. motivation the initial motivation came out of the need to create a smart contract account system that’s flexible enough to be viable long-term but also defined enough to be standardized. they are a generic set of two standardized building blocks to be used in all forms of smart contracts. this standard consists of two sub-standards, a generic data key/value store (erc725y) and a generic execute function (erc725x). both of these in combination allow for a very flexible and long-lasting account system. the account version of erc725 is standardized under lsp0-erc725account. these standards (erc725 x and y) can also be used separately as erc725y can be used to enhance nfts and token metadata or other types of smart contracts. erc725x allows for a generic execution through a smart contract, functioning as an account or actor. specification ownership this contract is controlled by a single owner. the owner can be a smart contract or an external account. this standard requires erc-173 and should implement the functions: owner() view transferownership(address newowner) and the event: ownershiptransferred(address indexed previousowner, address indexed newowner) erc725x erc725x interface id according to erc-165: 0x7545acac. smart contracts implementing the erc725x standard must implement the erc-165 supportsinterface(..) function and must support the erc165 and erc725x interface ids. erc725x methods smart contracts implementing the erc725x standard should implement all of the functions listed below: execute function execute(uint256 operationtype, address target, uint256 value, bytes memory data) external payable returns(bytes memory) function selector: 0x44c028fe executes a call on any other smart contracts or address, transfers the blockchains native token, or deploys a new smart contract. parameters: operationtype: the operation type used to execute. target: the smart contract or address to call. target will be unused if a contract is created (operation types 1 and 2). value: the amount of native tokens to transfer (in wei). data: the call data, or the creation bytecode of the contract to deploy. requirements: must only be called by the current owner of the contract. must revert when the execution or the contract creation fails. target should be address(0) in case of contract creation with create and create2 (operation types 1 and 2). value should be zero in case of staticcall or delegatecall (operation types 3 and 4). returns: bytes , the returned data of the called function, or the address of the contract deployed (operation types 1 and 2). triggers event: contractcreated, executed the following operationtype could exist: 0 for call 1 for create 2 for create2 3 for staticcall 4 for delegatecall note this is a potentially dangerous operation type others may be added in the future. data parameter for operationtype, call, staticcall and delegatecall the data field can be random bytes or an abi-encoded function call. for operationtype, create the data field is the creation bytecode of the contract to deploy appended with the constructor argument(s) abi-encoded. for operationtype, create2 the data field is the creation bytecode of the contract to deploy appended with: the constructor argument(s) abi-encoded a bytes32 salt. data = + + see eip-1014: skinny create2 for more information. executebatch function executebatch(uint256[] memory operationstype, address[] memory targets, uint256[] memory values, bytes[] memory datas) external payable returns(bytes[] memory) function selector: 0x31858452 executes a batch of calls on any other smart contracts, transfers the blockchain native token, or deploys a new smart contract. parameters: operationstype: the list of operations type used to execute. targets: the list of addresses to call. targets will be unused if a contract is created (operation types 1 and 2). values: the list of native token amounts to transfer (in wei). datas: the list of call data, or the creation bytecode of the contract to deploy. requirements: parameters array must have the same length. must only be called by the current owner of the contract. must revert when the execution or the contract creation fails. target should be address(0) in case of contract creation with create and create2 (operation types 1 and 2). value should be zero in case of staticcall or delegatecall (operation types 3 and 4). returns: bytes[] , array list of returned data of the called function, or the address(es) of the contract deployed (operation types 1 and 2). triggers event: contractcreated, executed on each call iteration erc725x events executed event executed(uint256 indexed operationtype, address indexed target, uint256 indexed value, bytes4 data); must be triggered when execute creates a new call using the operationtype 0, 3, 4. contractcreated event contractcreated(uint256 indexed operationtype, address indexed contractaddress, uint256 indexed value, bytes32 salt); must be triggered when execute creates a new contract using the operationtype 1, 2. erc725y erc725y interface id according to erc-165: 0x629aa694. smart contracts implementing the erc725y standard must implement the erc-165 supportsinterface(..) function and must support the erc165 and erc725y interface ids. erc725y methods smart contracts implementing the erc725y standard must implement all of the functions listed below: getdata function getdata(bytes32 datakey) external view returns(bytes memory) function selector: 0x54f6127f gets the data set for the given data key. parameters: datakey: the data key which value to retrieve. returns: bytes , the data for the requested data key. getdatabatch function getdatabatch(bytes32[] memory datakeys) external view returns(bytes[] memory) function selector: 0xdedff9c6 gets array of data at multiple given data keys. parameters: datakeys: the data keys which values to retrieve. returns: bytes[] , array of data values for the requested data keys. setdata function setdata(bytes32 datakey, bytes memory datavalue) external function selector: 0x7f23690c sets data as bytes in the storage for a single data key. parameters: datakey: the data key which value to set. datavalue: the data to store. requirements: must only be called by the current owner of the contract. triggers event: datachanged setdatabatch function setdatabatch(bytes32[] memory datakeys, bytes[] memory datavalues) external function selector: 0x97902421 sets array of data at multiple data keys. must only be called by the current owner of the contract. parameters: datakeys: the data keys which values to set. datavalues: the array of bytes to set. requirements: array parameters must have the same length. must only be called by the current owner of the contract. triggers event: datachanged erc725y events datachanged event datachanged(bytes32 indexed datakey, bytes datavalue) must be triggered when a data key was successfully set. erc725y data keys data keys, are the way to retrieve values via getdata(). these bytes32 values can be freely chosen, or defined by a standard. a common way to define data keys is the hash of a word, e.g. keccak256('ercxxxmynewkeytype') which results in: 0x6935a24ea384927f250ee0b954ed498cd9203fc5d2bf95c735e52e6ca675e047 the lsp2-erc725jsonschema standard is a more explicit erc725y data key standard, that defines key types and value types, and their encoding and decoding. rationale the generic way of storing data keys with values was chosen to allow upgradability over time. stored data values can be changed over time. other smart contract protocols can then interpret this data in new ways and react to interactions from a erc725 smart contract differently. the data stored in an erc725y smart contract is not only readable/writable by off-chain applications, but also by other smart contracts. function overloading was used to allow for the retrievable of single and multiple keys, to keep gas costs minimal for both use cases. backwards compatibility all contracts since erc725v2 from 2018/19 should be compatible with the current version of the standard. mainly interface id and event parameters have changed, while getdata(bytes32[]) and setdata(bytes32[], bytes[]) was added as an efficient way to set/get multiple keys at once. the same applies to execution, as execute(..[]) was added as an efficient way to batch calls. from 2023 onward, overloading was removed from erc-725 (including erc725-x and erc725-y). this is because, while overloading is accommodated in solidity, it isn’t broadly supported across most blockchain languages. in order to make the standard language-independent, it was decided to shift from overloading to simply attach the term “batch” to the functions that accept an array as parameters. reference implementation reference implementations can be found in erc725.sol. security considerations this contract allows generic executions, therefore special care needs to be taken to prevent re-entrancy attacks and other forms of call chain attacks. when using the operation type 4 for delegatecall, it is important to consider that the called contracts can alter the state of the calling contract and also change owner variables and erc725y data storage entries at will. additionally calls to selfdestruct are possible and other harmful state-changing operations. solidity interfaces // spdx-license-identifier: cc0-1.0 pragma solidity >=0.5.0 <0.7.0; // erc165 identifier: `0x7545acac` interface ierc725x /* is erc165, erc173 */ { event executed(uint256 indexed operationtype, address indexed target, uint256 indexed value, bytes4 data); event contractcreated(uint256 indexed operationtype, address indexed contractaddress, uint256 indexed value, bytes32 salt); function execute(uint256 operationtype, address target, uint256 value, bytes memory data) external payable returns(bytes memory); function executebatch(uint256[] memory operationstype, address[] memory targets, uint256[] memory values, bytes memory datas) external payable returns(bytes[] memory); } // erc165 identifier: `0x629aa694` interface ierc725y /* is erc165, erc173 */ { event datachanged(bytes32 indexed datakey, bytes datavalue); function getdata(bytes32 datakey) external view returns(bytes memory); function getdatabatch(bytes32[] memory datakeys) external view returns(bytes[] memory); function setdata(bytes32 datakey, bytes memory datavalue) external; function setdatabatch(bytes32[] memory datakeys, bytes[] memory datavalues) external; } interface ierc725 /* is ierc725x, ierc725y */ { } copyright copyright and related rights waived via cc0. citation please cite this document as: fabian vogelsteller (@frozeman), tyler yasaka (@tyleryasaka), "erc-725: general data key/value store and execution [draft]," ethereum improvement proposals, no. 725, october 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-725. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3046: adds `basefee` to `eth_getunclebyblocknumberandindex` ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3046: adds `basefee` to `eth_getunclebyblocknumberandindex` authors abdelhamid bakhta (@abdelhamidbakhta) created 2020-10-14 discussion link https://ethereum-magicians.org/t/add-basefee-to-eth-getunclebyblocknumberandindex/4830 requires eip-1474, eip-1559 table of contents simple summary abstract motivation specification eth_getunclebyblocknumberandindex rationale backwards compatibility security considerations copyright simple summary add basefee field to eth_getunclebyblocknumberandindex rpc endpoint response. abstract adds basefee property to the eth_getunclebyblocknumberandindex json-rpc request result object. this property will contain the value of the base fee for any block after the eip-1559 fork. motivation eip-1559 introduces a base fee per gas in protocol. this value is maintained under consensus as a new field in the block header structure. users may need value of the base fee at a given block. base fee value is important to make gas price predictions more accurate. specification eth_getunclebyblocknumberandindex description returns information about an uncle specified by block number and uncle index position every block returned by this endpoint whose block number is before the eip-1559 fork block must not include a basefee field. every block returned by this endpoint whose block number is on or after the eip-1559 fork block must include a basefee field. parameters parameters remain unchanged. returns for the full specification of eth_getunclebyblocknumberandindex see eip-1474. add a new json field to the result object for block headers containing a base fee (post eip-1559 fork block). {quantity} basefee base fee for this block example # request curl -x post --data '{ "id": 1559, "jsonrpc": "2.0", "method": "eth_getunclebyblocknumberandindex", "params":["latest", "0x0"] }' # response { "id": 1559, "jsonrpc": "2.0", "result": { "difficulty": "0x027f07", "extradata": "0x0000000000000000000000000000000000000000000000000000000000000000", "basefee": "0x7" "gaslimit": "0x9f759", "gasused": "0x9f759", "hash": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "logsbloom": "0xe670ec64341771606e55d6b4ca35a1a6b75ee3d5145a99d05921026d1527331", "miner": "0x4e65fda2159562a496f9f3522f89122a3088497a", "nonce": "0xe04d296d2460cfb8472af2c5fd05b5a214109c25688d3704aed5484f9a7792f2", "number": "0x1b4", "parenthash": "0x9646252be9520f6e71339a8df9c55e4d7619deeb018d2a3f2d21fc165dde5eb5", "sha3uncles": "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347", "size": "0x027f07", "stateroot": "0xd5855eb08b3387c0af375e9cdb6acfc05eb8f519e419b874b6ff2ffda7ed1dff", "timestamp": "0x54e34e8e" "totaldifficulty": "0x027f07", "transactions": [] "transactionsroot": "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421", "uncles": [] } } rationale the addition of a single parameter instead of introducing a whole new endpoint was the simplest change that would be easiest to get integrated. for backward compatibility we decided to not include the base fee in the response for pre-1559 blocks. backwards compatibility backwards compatible. calls related to block prior to eip-1559 fork block will omit the base fee field in the response. security considerations the added field (basefee) is informational and does not introduce technical security issues. copyright copyright and related rights waived via cc0. citation please cite this document as: abdelhamid bakhta (@abdelhamidbakhta), "eip-3046: adds `basefee` to `eth_getunclebyblocknumberandindex` [draft]," ethereum improvement proposals, no. 3046, october 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-3046. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-162: initial ens hash registrar ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-162: initial ens hash registrar authors maurelian, nick johnson , alex van de sande created 2016-10-25 table of contents contents abstract motivations specification initial restrictions name format for hash registration auctioning names deeds deployment and upgrade process planned deactivation registrar interface rationale starting with a temporary registrar valid names >= 7 characters delayed release of names restricting tld to .eth holding ether as collateral prior work edits: copyright contents abstract motivations specification initial restrictions name format for hash registration auctioning names deeds deployment and upgrade process registrar interface rationale not committing to a permanent registrar at the outset valid names >= 7 characters restricting tld to .eth holding ether as collateral prior work abstract this erc describes the implementation, as deployed to the main ethereum network on 2017-05-04, of a registrar contract to govern the allocation of names in the ethereum name service (ens). the corresponding source code is here. for more background, refer to eip-137. registrars are responsible for allocating domain names to users of the system, and are the only entities capable of updating the ens; the owner of a node in the ens registry is its registrar. registrars may be contracts or externally owned accounts, though it is expected that the root and top-level registrars, at a minimum, will be implemented as contracts. eip 137 a well designed and governed registrar is essential to the success of the ens described in eip 137, but is described separately in this document as it is external to the core ens protocol. in order to maximize utility and adoption of a new namespace, the registrar should mitigate speculation and “name squatting”, however the best approach for mitigation is unclear. thus an “initial” registrar is proposed, which implements a simple approach to name allocation. during the initial period, the available namespace will be significantly restricted to the .eth top level domain, and subdomain shorter than 7 characters in length disallowed. this specification largely describes @alexvandesande and @arachnid’s hash registrar implementation in order to facilitate discussion. the intent is to replace the initial registrar contract with a permanent registrar contract. the permanent registrar will increase the available namespace, and incorporate lessons learned from the performance of the initial registrar. this upgrade is expected to take place within approximately 2 years of initial deployment. motivations the following factors should be considered in order to optimize for adoption of the ens, and good governance of the initial registrar’s namespace. upgradability: the initial registrar should be safely upgradeable, so that knowledge gained during its deployment can be used to replace it with an improved and permanent registrar. effective allocation: newly released namespaces often create a land grab situation, resulting in many potentially valuable names being purchased but unused, with the hope of re-selling at a profit. this reduces the availability of the most useful names, in turn decreasing the utility of the name service to end users. achieving an effective allocation may or may not require human intervention for dispute resolution and other forms of curation. the initial registrar should not aim to create to most effective possible allocation, but instead limit the cost of misallocation in the long term. security: the registrar will hold a balance of ether without an explicit limit. it must be designed securely. simplicity: the ens specification itself emphasizes a separation of concerns, allowing the most essential element, the registry to be as simple as possible. the interim registrar in turn should be as simple as possible while still meeting its other design goals. adoption: successful standards become more successful due to network effects. the registrar should consider what strategies will encourage the adoption of the ens in general, and the namespace it controls in particular. specification initial restrictions the initial registrar is expected to be in service for approximately two years, prior to upgrading. this should be sufficient time to learn, observe, and design an updated system. during the initial two year period, the available name space will be restricted to the .eth tld. this restriction is enforced by the owner of the ens root node who should not assign any nodes other than .eth to the initial registrar. the ens’s root node should be controlled by multiple parties using a multisig contract. the initial registrar will also prohibit registration of names 6 characters or less in length. name format for hash registration names submitted to the initial registrar must be hashed using ethereum’s sha3 function. note that the hashes submitted to the registrar are the hash of the subdomain label being registered, not the namehash as defined in eip 137. for example, in order to register abcdefg.eth, one should submit sha3('abcdefg'), not sha3(sha3(0, 'eth'), 'abcdefg'). auctioning names the registrar will allocate the available names through a vickrey auction: a vickrey auction is a type of sealed-bid auction. bidders submit written bids without knowing the bid of the other people in the auction. the highest bidder wins but the price paid is the second-highest bid. this type of auction… gives bidders an incentive to bid their true value. vickrey auction, wikipedia the auction lifecycle of a name has 5 possible states, or modes. not-yet-available: the majority of names will be initially unavailable for auction, and will become available some time during the 8 weeks after launch. open: the earliest availability for a name is determined by the most significant byte of its sha3 hash. 0x00 would become available immediately, 0xff would become available after 8 weeks, and the availability of other names is distributed accordingly. once a name is available, it is possible to start an auction on it. auction: once the auction for a name has begun, there is a 72 hour bidding period. bidders must submit a payment of ether, along with sealed bids as a hash of sha3(bytes32 hash, address owner, uint value, bytes32 salt). the bidder may obfuscate the true bid value by sending a greater amount of ether. reveal: after the bidding period, a 48 hour reveal period commences. during this time, bidders must reveal the true parameters of their sealed bid. as bids are revealed, ether payments are returned according to the schedule of “refund ratios” outlined in the table below. if no bids are revealed, the name will return to the open state. owned: after the reveal period has finished, the winning bidder must submit a transaction to finalize the auction, which then calls the ens’s setsubnodeowner function, recording the winning bidder’s address as the owner of the hash of the name. the following table outlines important parameters which define the registrar’s auction mechanism. registrar parameters name description value totalauctionlength the full time period from start of auction to end of the reveal period. 5 days revealperiod the length of the time period during which bidding is no longer allowed, and bids must be revealed. 48 hours launchlength the time period during which all names will become available for auction. 8 weeks minprice the minimum amount of ether which must be locked up in exchange for ownership of a name. 0.01 ether deeds the initial registrar contract does not hold a balance itself. all ether sent to the registrar will be held in a separate deed contracts. a deed contract is first created and funded when a sealed bid is submitted. after an auction is completed and a hash is registered, the deed for the winning bid is held in exchange for ownership of the hash. non-winning bids are refunded. a deed for an owned name may be transferred to another account by its owner, thus transferring ownership and control of the name. after 1 year of registration, the owner of a hash may choose to relinquish ownership and have the value of the deed returned to them. deeds for non-winning bids can be closed by various methods, at which time any ether held will either be returned to the bidder, burnt, or sent to someone else as a reward for actions which help the registrar. the following table outlines what portion of the balance held in a deed contract will be returned upon closure, and to whom. the remaining balance will be burnt. refund schedule reason for deed closure refund recipient refund percentage a valid non-winning bid is revealed. bidder 99.5% a bid submitted after the auction period is revealed. bidder 99.5% an otherwise valid bid is revealed on an owned name. 1 bidder 0.5% an expired sealed bid is cancelled. 2 canceler 0.5% a registered hash is reported as invalid. 3 reporter 50% a registered hash is reported as invalid. 3 owner 50% notes: this incentivizes all bids to be revealed in time. if bids could be revealed late, an extortion attack on the current highest bidder could be made by threatening to reveal a new second highest bid. a bid which remains sealed after more than 2 weeks and 5 days may be cancelled by anyone to collect a small reward. since names are hashed before auctioning and registration, the initial registrar is unable to enforce character length restrictions independently. a reward is therefore provided for reporting invalid names. deployment and upgrade process the initial registrar requires the ens’s address as a constructor, and should be deployed after the ens. the multisig account owning the root node in the ens should then set the initial registrar’s address as owner of the eth node. the initial registrar is expected to be replaced by a permanent registrar approximately 2 years after deployment. the following process should be used for the upgrade: the permanent registrar contract will be deployed. the multisig account owning the root node in the ens will assign ownership of the .eth node to the permanent registrar. owners of hashes in the initial registrar will be responsible for registering their deeds to the permanent registrar. a couple options are considered here: require owners to transfer their ownership prior to a cutoff date in order to maintain ownership and/or continue name resolution services. have the permanent registrar query the initial registrar for ownership if it is lacking an entry. planned deactivation in order to limit dependence on the initial registrar, new auctions will stop after 4 years, and all ether held in deeds after 8 years will become unreachable. registrar interface function state(bytes32 _hash) constant returns (mode) implements a state machine returning the current state of a name function entries(bytes32 _hash) constant returns (mode, address, uint, uint, uint) returns the following information regarding a registered name: state deed address registration date balance of the deed highest value bid at auction function getallowedtime(bytes32 _hash) constant returns (uint timestamp) returns the time at which the hash will no longer be in the initial not-yet-available state. function isallowed(bytes32 _hash, uint _timestamp) constant returns (bool allowed) takes a hash and a time, returns true if and only if it has passed the initial not-yet-available state. function startauction(bytes32 _hash); moves the state of a hash from open to auction. throws if state is not open. function startauctions(bytes32[] _hashes); starts multiple auctions on an array of hashes. this enables someone to open up an auction for a number of dummy hashes when they are only really interested in bidding for one. this will increase the cost for an attacker to simply bid blindly on all new auctions. dummy auctions that are open but not bid on are closed after a week. function shabid(bytes32 hash, address owner, uint value, bytes32 salt) constant returns (bytes32 sealedbid); takes the parameters of a bid, and returns the sealedbid hash value required to participate in the bidding for an auction. this obfuscates the parameters in order to mimic the mechanics of placing a bid in an envelope. function newbid(bytes32 sealedbid); bids are sent by sending a message to the main contract with a sealedbid hash and an amount of ether. the hash contains information about the bid, including the bidded name hash, the bid value, and a random salt. bids are not tied to any one auction until they are revealed. the value of the bid itself can be masqueraded by sending more than the value of your actual bid. this is followed by a 48h reveal period. bids revealed after this period will be burned and the ether unrecoverable. since this is an auction, it is expected that most public hashes, like known domains and common dictionary words, will have multiple bidders pushing the price up. function startauctionsandbid(bytes32[] hashes, bytes32 sealedbid) a utility function allowing a call to startauctions followed by newbid in a single transaction. function unsealbid(bytes32 _hash, address _owner, uint _value, bytes32 _salt); once the bidding period is completed, there is a reveal period during with the properties of a bid are submitted to reveal them. the registrar hashes these properties using the shabid() function above to verify that they match a pre-existing sealed bid. if the unsealedbid is the new best bid, the old best bid is returned to its bidder. function cancelbid(bytes32 seal); cancels an unrevealed bid according to the rules described in the notes on the refund schedule above. function finalizeauction(bytes32 _hash); after the registration date has passed, this function can be called to finalize the auction, which then calls the ens function setsubnodeowner() updating the ens record to set the winning bidder as owner of the node. function transfer(bytes32 _hash, address newowner); update the owner of the ens node corresponding to the submitted hash to a new owner. this function must be callable only by the current owner. function releasedeed(bytes32 _hash); after some time, the owner can release the property and get their ether back. function invalidatename(string unhashedname); since registration is done on the hash of a name, the registrar itself cannot validate names. this function can be used to report a name which is 6 characters long or less. if it has been registered, the submitter will earn 10% of the deed value. we are purposefully handicapping the simplified registrar as a way to force it into being restructured in a few years. function erasenode(bytes32[] labels) allows anyone to delete the owner and resolver records for a subdomain of a name that is not currently owned in the registrar. for instance, to zero foo.bar.eth on a registrar that owns .eth, pass an array containing [sha3('foo'), sha3('bar')]. function transferregistrars(bytes32 _hash) onlyowner(_hash); used during the upgrade process to a permanent registrar. if this registrar is no longer the owner of the its root node in the ens, this function will transfers the deed to the current owner, which should be a new registrar. this function throws if this registrar still owns its root node. rationale starting with a temporary registrar anticipating and designing for all the potential issues of name allocation names is unlikely to succeed. this approach chooses not to be concerned with getting it perfect, but allows us to observe and learn with training wheels on, and implement improvements before expanding the available namespace to shorter names or another tld. valid names >= 7 characters preserving the shortest, and often most valuable, domain names for the upgraded registrar provides the opportunity to implement processes for dispute resolution (assuming they are found to be necessary). delayed release of names a slower release allows for extra time to identify, and address any issues which may arise after launch. restricting tld to .eth choosing a single tld helps to maximize network effects by focusing on one namespace. a three letter tld is a pattern made familiar by it’s common usage in internet domain names. this familiarity significantly increases the potential of the ens to be integrated into pre-existing dns systems, and reserved as a special-use domain name. a recent precedent for this is the reservation of the .onion domain. holding ether as collateral this approach is simpler than the familiar model of requiring owners to make recurring payments to retain ownership of a domain name. it also makes the initial registrar a revenue neutral service. prior work this document borrows heavily from several sources: eip-137 outlines the initial implementation of the registry contract (ens.sol) and associated resolver contracts. erc-26 was the first erc to propose a name service at the contract layer @alexvandesande’s current implementation of the hashregistrar edits: 2016-10-26 added link alex’s design in abstract 2016-11-01 change ‘planned deactivation’ to h3’ 2017-03-13 update timelines for bidding and reveal periods copyright copyright and related rights waived via cc0. citation please cite this document as: maurelian, nick johnson , alex van de sande , "erc-162: initial ens hash registrar," ethereum improvement proposals, no. 162, october 2016. [online serial]. available: https://eips.ethereum.org/eips/eip-162. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7092: financial bonds ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 📢 last call standards track: erc erc-7092: financial bonds represents debt issued by entities to investors. authors samuel gwlanold edoumou (@edoumou) created 2023-05-28 last call deadline 2024-02-07 requires eip-165 this eip is in the process of being peer-reviewed. if you are interested in this eip, please participate using this discussion link. table of contents abstract motivation specification additional bond parameters interface cross-chain interface rationale total supply and account balance backwards compatibility reference implementation callable bonds: puttable bonds: convertible bonds: identity registry security considerations copyright abstract this proposal introduces fixed-income financial bonds with key characteristics defined to facilitate bond issuance in the primary market and enable buying or selling bonds in the secondary market. the standard also provides cross-chain functionalities for bonds operations and management accross multiple blockchains. motivation fixed-income instruments are a widely utilized asset class for corporations and other entities raising funds. however, transitioning to tokenized bonds is challenging due to existing standards like erc-3475, which introduces unfamiliar concepts and leads to unnecessary gas consumption. additionally, the lack of named variables like coupon, maturity date, and principal, makes it difficult to implement erc-3475 since developers need to remember which metadata is assigned to each parameter. 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. every contract compliant with this erc must implement the following token interface as well as the erc-165 interface: // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; /** * @title erc-7092 financial bonds standard */ interface ierc7092 /** is erc165 */ { // events /** * @notice must be emitted when bond tokens are transferred, issued or redeemed, except during contract creation * @param _from the account that owns bonds * @param _to the account that receives the bond * @param _amount amount of bond tokens to be transferred */ event transfer(address indexed _from, address indexed _to, uint256 _amount); /** * @notice must be emitted when an account is approved or when the allowance is decreased * @param _owner bond token's owner * @param _spender the account to be allowed to spend bonds * @param _amount amount of bond tokens allowed by _owner to be spent by `_spender` * or amount of bond tokens to decrease allowance from `_spender` */ event approval(address indexed _owner, address indexed _spender, uint256 _amount); /** * @notice must be emitted when multiple bond tokens are transferred, issued or redeemed, with the exception being during contract creation * @param _from array of bondholders accounts * @param _to array of accounts to transfer bonds to * @param _amount array of amounts of bond tokens to be transferred * ** optional interfaces and other contracts must not expect this function to be present. must be emitted in `batchtransfer` and `batchtransferfrom` functions */ event transferbatch(address[] _from, address[] _to, uint256[] _amount); /** * @notice must be emitted when multiple accounts are approved or when the allowance is decreased from multiple accounts * @param _owner bondholder account * @param _spender array of accounts to be allowed to spend bonds, or to decrase the allowance from * @param _amount array of amounts of bond tokens allowed by `_owner` to be spent by multiple accounts in `_spender`. * ** optional interfaces and other contracts must not expect this function to be present. must be emitted in `batchapprove` and `batchdecreaseallowance` functions */ event approvalbatch(address indexed _owner, address[] _spender, uint256[] _amount); // getter functions /** * @notice returns the bond isin */ function isin() external view returns(string memory); /** * @notice returns the bond name */ function name() external view returns(string memory); /** * @notice returns the bond symbol * it is recommended to represent the symbol as a combination of the issuer issuer'shorter name and the maturity date * ex: if a company named green energy issues bonds that will mature on october 25, 2030, the bond symbol could be `ge30` or `ge2030` or `ge102530` */ function symbol() external view returns(string memory); /** * @notice returns the bond currency. this is the contract address of the token used to pay and return the bond principal */ function currency() external view returns(address); /** * @notice returns the bond denominiation. this is the minimum amount in which the bonds may be issued. it must be expressend in unit of the principal currency * ex: if the denomination is equal to 1,000 and the currency is usdc, then the bond denomination is equal to 1,000 usdc */ function denomination() external view returns(uint256); /** * @notice returns the issue volume (total debt amount). it is recommended to express the issue volume in denomination unit. */ function issuevolume() external view returns(uint256); /** * @notice returns the bond interest rate. it is recommended to express the interest rate in basis point unit. * 1 basis point = 0.01% = 0.0001 * ex: if interest rate = 5%, then coupon() => 500 basis points */ function couponrate() external view returns(uint256); /** * @notice returns the date when bonds were issued to investors. this is a unix timestamp like the one returned by block.timestamp */ function issuedate() external view returns(uint256); /** * @notice returns the bond maturity date, i.e, the date when the pricipal is repaid. this is a unix timestamp like the one returned by block.timestamp * the maturity date must be greater than the issue date */ function maturitydate() external view returns(uint256); /** * @notice returns the principal of an account. it is recommended to express the principal in the bond currency unit (usdc, dai, etc...) * @param _account account address */ function principalof(address _account) external view returns(uint256); /** * @notice returns the amount of tokens the `_spender` account has been authorized by the `_owner`` * acount to manage their bonds * @param _owner the bondholder address * @param _spender the address that has been authorized by the bondholder */ function allowance(address _owner, address _spender) external view returns(uint256); // setter functions /** * @notice authorizes `_spender` account to manage `_amount`of their bond tokens * @param _spender the address to be authorized by the bondholder * @param _amount amount of bond tokens to approve */ function approve(address _spender, uint256 _amount) external returns(bool); /** * @notice lowers the allowance of `_spender` by `_amount` * @param _spender the address to be authorized by the bondholder * @param _amount amount of bond tokens to remove from allowance */ function decreaseallowance(address _spender, uint256 _amount) external returns(bool); /** * @notice moves `_amount` bonds to address `_to`. this methods also allows to attach data to the token that is being transferred * @param _to the address to send the bonds to * @param _amount amount of bond tokens to transfer * @param _data additional information provided by the token holder */ function transfer(address _to, uint256 _amount, bytes calldata _data) external returns(bool); /** * @notice moves `_amount` bonds from an account that has authorized the caller through the approve function * this methods also allows to attach data to the token that is being transferred * @param _from the bondholder address * @param _to the address to transfer bonds to * @param _amount amount of bond tokens to transfer. * @param _data additional information provided by the token holder */ function transferfrom(address _from, address _to, uint256 _amount, bytes calldata _data) external returns(bool); // batch functions /** * @notice authorizes multiple spender accounts to manage a specified `_amount` of the bondholder tokens * @param _spender array of accounts to be authorized by the bondholder * @param _amount array of amounts of bond tokens to approve * * optional interfaces and other contracts must not expect these values to be present. the method is used to improve usability. */ function batchapprove(address[] calldata _spender, uint256[] calldata _amount) external returns(bool); /** * @notice decreases the allowance of multiple spenders by corresponding amounts in `_amount` * @param _spender array of accounts to be authorized by the bondholder * @param _amount array of amounts of bond tokens to decrease the allowance from * * optional interfaces and other contracts must not expect this function to be present. the method is used to decrease token allowance. */ function batchdecreaseallowance(address[] calldata _spender, uint256[] calldata _amount) external returns(bool); /** * @notice transfers multiple bonds with amounts specified in the array `_amount` to the corresponding accounts in the array `_to`, with the option to attach additional data * @param _to array of accounts to send the bonds to * @param _amount array of amounts of bond tokens to transfer * @param _data array of additional information provided by the token holder * * optional interfaces and other contracts must not expect this function to be present. */ function batchtransfer(address[] calldata _to, uint256[] calldata _amount, bytes[] calldata _data) external returns(bool); /** * @notice transfers multiple bonds with amounts specified in the array `_amount` to the corresponding accounts in the array `_to` from an account that have been authorized by the `_from` account * this method also allows to attach data to tokens that are being transferred * @param _from array of bondholder accounts * @param _to array of accounts to transfer bond tokens to * @param _amount array of amounts of bond tokens to transfer. * @param _data array of additional information provided by the token holder * ** optional interfaces and other contracts must not expect this function to be present. */ function batchtransferfrom(address[] calldata _from, address[] calldata _to, uint256[] calldata _amount, bytes[] calldata _data) external returns(bool); } additional bond parameters interface the ierc7092esg interface is optional for contracts implementing this proposal. this interface may be used to improve the standard usability. the currencyofcoupon the currency used for coupon payment may be different from the currency used to repay the principal the coupontype may be employed to signify the interest rate that the issuer has committed to paying to investors, which may take various forms such as zero coupon, fixed rate, floating rate, and more. the couponfrequency refers to how often the bond pays interest to its bondholders, and is typically expressed in terms of time periods, such as: annual, semi-annual, quarterly, or monthly. the daycountbasis is used to calculate the accrued interest on a bond between two coupon payment dates or other specific periods. some of the day count basis are: actual/actual, 30/360, actual/360, actual/365, or 30/365 // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; interface ierc7092esg /** is erc165 */ { /** * @notice returns the number of decimals used by the bond. for example, if it returns `10`, it means that the token amount must be multiplied by 10000000000 to get the standard representation. */ function decimals() external view returns(uint8); /** * @notice rreturns the coupon currency, which is represented by the contract address of the token used to pay coupons. it can be the same as the one used for the principal */ function currencyofcoupon() external view returns(address); /** * @notice returns the coupon type * for example, 0 can denote zero coupon, 1 can denote fixed rate, 2 can denote floating rate, and so on */ function coupontype() external view returns(uint8); /** * @notice returns the coupon frequency, i.e. the number of times coupons are paid in a year. */ function couponfrequency() external view returns(uint256); /** * @notice returns the day count basis * for example, 0 can denote actual/actual, 1 can denote actual/360, and so on */ function daycountbasis() external view returns(uint8); } cross-chain interface the standard permits the implementation of the ierc7092crosschain interface for cross-chain management of bond tokens. this interface is optional and may be used by applications to allow cross-chain transactions. any function initiating a cross-chain transaction must explicitly define the destination chain identifier destinationchainid and specify the target smart contract destinationcontract. // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; interface ierc7092crosschain /** is erc165 */ { // events /** * @notice must be emitted when bond tokens are transferred or redeemed in a cross-chain transaction * @param _from bondholder account * @param _to account the transfer bond tokens to * @param _amount amount of bond tokens to be transferred * @param _destinationchainid the unique id that identifies the destination chain */ event crosschaintransfer(address indexed _from, address indexed _to, uint256 _amount, bytes32 _destinationchainid); /** * @notice must be emitted when several bond tokens are transferred or redeemed in a cross-chain transaction * @param _from array of bondholders accounts * @param _to array of accounts that receive the bond * @param _amount array of amount of bond tokens to be transferred * @param _destinationchainid array of unique ids that identify the destination chain */ event crosschaintransferbatch(address[] _from, address[] _to, uint256[] _amount, bytes32[] _destinationchainid); /** * @notice must be emitted when an account is approved to spend the bondholder's tokens in a different chain than the current chain * @param _owner the bondholder account * @param _spender the account to be allowed to spend bonds * @param _amount amount of bond tokens allowed by `_owner` to be spent by `_spender` * @param _destinationchainid the unique id that identifies the destination chain */ event crosschainapproval(address indexed _owner, address indexed _spender, uint256 _amount, bytes32 _destinationchainid); /** * @notice must be emitted when multiple accounts in the array `_spender` are approved or when the allowances of multiple accounts in the array `_spender` are reduced on the destination chain which must be different than the current chain * @param _owner bond token's owner * @param _spender array of accounts to be allowed to spend bonds * @param _amount array of amount of bond tokens allowed by _owner to be spent by _spender * @param _destinationchainid array of unique ids that identify the destination chain */ event crosschainapprovalbatch(address indexed _owner, address[] _spender, uint256[] _amount, bytes32[] _destinationchainid); // functions /** * @notice authorizes the `_spender` account to manage a specified `_amount`of the bondholder bond tokens on the destination chain * @param _spender account to be authorized by the bondholder * @param _amount amount of bond tokens to approve * @param _destinationchainid the unique id that identifies the destination chain. * @param _destinationcontract the smart contract to interact with in the destination chain */ function crosschainapprove(address _spender, uint256 _amount, bytes32 _destinationchainid, address _destinationcontract) external returns(bool); /** * @notice authorizes multiple spender accounts in `_spender` to manage specified amounts in `_amount` of the bondholder tokens on the destination chain * @param _spender array of accounts to be authorized by the bondholder * @param _amount array of amounts of bond tokens to approve * @param _destinationchainid array of unique ids that identifies the destination chain. * @param _destinationcontract array of smart contracts to interact with in the destination chain in order to deposit or mint tokens that are transferred. */ function crosschainbatchapprove(address[] calldata _spender, uint256[] calldata _amount, bytes32[] calldata _destinationchainid, address[] calldata _destinationcontract) external returns(bool); /** * @notice decreases the allowance of `_spender` by a specified `_amount` on the destination chain * @param _spender the address to be authorized by the bondholder * @param _amount amount of bond tokens to remove from allowance * @param _destinationchainid the unique id that identifies the destination chain. * @param _destinationcontract the smart contract to interact with in the destination chain in order to deposit or mint tokens that are transferred. */ function crosschaindecreaseallowance(address _spender, uint256 _amount, bytes32 _destinationchainid, address _destinationcontract) external returns(bool); /** * @notice decreases the allowance of multiple spenders in `_spender` by corresponding amounts specified in the array `_amount` on the destination chain * @param _spender array of accounts to be authorized by the bondholder * @param _amount array of amounts of bond tokens to decrease the allowance from * @param _destinationchainid array of unique ids that identifies the destination chain. * @param _destinationcontract array of smart contracts to interact with in the destination chain in order to deposit or mint tokens that are transferred. */ function crosschainbatchdecreaseallowance(address[] calldata _spender, uint256[] calldata _amount, bytes32[] calldata _destinationchainid, address[] calldata _destinationcontract) external returns(bool); /** * @notice moves `_amount` bond tokens to the address `_to` from the current chain to another chain (e.g., moving tokens from ethereum to polygon). * this methods also allows to attach data to the token that is being transferred * @param _to account to send bond tokens to * @param _amount amount of bond tokens to transfer * @param _data additional information provided by the bondholder * @param _destinationchainid the unique id that identifies the destination chain. * @param _destinationcontract the smart contract to interact with in the destination chain in order to deposit or mint bond tokens that are transferred. */ function crosschaintransfer(address _to, uint256 _amount, bytes calldata _data, bytes32 _destinationchainid, address _destinationcontract) external returns(bool); /** * @notice transfers multiple bond tokens with amounts specified in the array `_amount` to the corresponding accounts in the array `_to` from the current chain to another chain (e.g., moving tokens from ethereum to polygon). * this methods also allows to attach data to the token that is being transferred * @param _to array of accounts to send the bonds to * @param _amount array of amounts of bond tokens to transfer * @param _data array of additional information provided by the bondholder * @param _destinationchainid array of unique ids that identify the destination chains. * @param _destinationcontract array of smart contracts to interact with in the destination chains in order to deposit or mint bond tokens that are transferred. */ function crosschainbatchtransfer(address[] calldata _to, uint256[] calldata _amount, bytes[] calldata _data, bytes32[] calldata _destinationchainid, address[] calldata _destinationcontract) external returns(bool); /** * @notice transfers `_amount` bond tokens from the `_from`account to the `_to` account from the current chain to another chain. the caller must be approved by the `_from` address. * this methods also allows to attach data to the token that is being transferred * @param _from the bondholder address * @param _to the account to transfer bonds to * @param _amount amount of bond tokens to transfer * @param _data additional information provided by the token holder * @param _destinationchainid the unique id that identifies the destination chain. * @param _destinationcontract the smart contract to interact with in the destination chain in order to deposit or mint tokens that are transferred. */ function crosschaintransferfrom(address _from, address _to, uint256 _amount, bytes calldata _data, bytes32 _destinationchainid, address _destinationcontract) external returns(bool); /** * @notice transfers several bond tokens with amounts specified in the array `_amount` from accounts in the array `_from` to accounts in the array `_to` from the current chain to another chain. * the caller must be approved by the `_from` accounts to spend the corresponding amounts specified in the array `_amount` * this methods also allows to attach data to the token that is being transferred * @param _from array of bondholder addresses * @param _to array of accounts to transfer bonds to * @param _amount array of amounts of bond tokens to transfer * @param _data array of additional information provided by the token holder * @param _destinationchainid array of unique ids that identifies the destination chain. * @param _destinationcontract array of smart contracts to interact with in the destination chain in order to deposit or mint tokens that are transferred. */ function crosschainbatchtransferfrom(address[] calldata _from, address[] calldata _to, uint256[] calldata _amount, bytes[] calldata _data, bytes32[] calldata _destinationchainid, address[] calldata _destinationcontract) external returns(bool); } rationale the design of this erc aims to simplify the migration to tokenized bonds by maintaining consistency with traditional bond standards. this approach allows fixed-income instruments to be represented as on-chain tokens, manageable through wallets, and utilized by applications like decentralized exchanges, while avoiding the complexities and inefficiencies associated with other standards. this erc facilitates the creation of new bond tokens with characteristics akin to traditional bonds, enhancing accessibility, liquidity, and cost-efficiency in bond trading and management. the use of traditional finance terminology, like issuevolume and principalof, is aimed at maintaining consistency with traditional bond language, which eases the adaptation for traditional entities. total supply and account balance the totalsupply and balanceof functions are not defined as they can be derived from issuevolume and principalof, and denomination. however, these functions can be be added in any contract implementing this standard, ensuring the proper relationship between these values. function totalsupply() external view returns(uint256) { return issuevolume() / denomination(); } function balance0f(account) external view returns(uint256) { return principal(account) / denomination(); } backwards compatibility this erc is not backwards compatible with existing standards like erc-20 or erc-1155 due to the absence of certain functions like totalsupply or balanceof. a pure implementation of this standard is recommended for issuing tokenized bonds, as any hybrid solution with other mentioned standards should fail. reference implementation the complete reference implementation can be found here. bonds with embedded options like callable, puttable, or convertible bonds can be created by inheriting from the reference erc7092.sol that integrates the proposed interface. callable bonds: pragma solidity ^0.8.0; import 'erc7092.sol'; contract erc7092callable is erc7092 { // write the logic to allow the issuer to call bonds // state variables and functions needed /** * @notice call bonds owned by `_investor` * must be called by the issuer only */ function call(address _investor) public { require(msg.sender == _issuer[bondisin].issueraddress, "erc7092callable: only_issuer"); require(_principals[_investor] > 0, "erc7092callable: no_bonds"); require(block.timestamp < _bond[bondisin].maturitydate, "erc7092callable: bond_matured"); uint256 principal = _principals[_investor]; _principals[_investor] = 0; // add logic here } } puttable bonds: pragma solidity ^0.8.0; import 'erc7092.sol'; contract erc7092puttable is erc7092 { // write the logic to allow investors to put bonds // state variables and functions needed /** * @notice put bonds * must be called by investors who own bonds */ function put() public { require(_principals[msg.sender] > 0, "erc7092puttable: only_investors"); require(block.timestamp < _bond[bondisin].maturitydate, "erc7092puttable: bond_matured"); uint256 principal = _principals[msg.sender]; _principals[msg.sender] = 0; // add logic } } convertible bonds: pragma solidity ^0.8.0; import 'erc7092.sol'; contract erc7092convertible is erc7092 { // write the logic to allow investor or issuer to convert bonds to equity // state variables and functions needed /** * @notice convert bonds to equity. here we assumed that the investors must convert their bonds to equity * issuer can also convert invetsors bonds to equity. */ function convert() public { require(_principals[msg.sender] > 0, "erc7092convertible: only_investors"); require(block.timestamp < _bond[bondisin].maturitydate, "erc7092convertible: bond_matured"); uint256 principal = _principals[msg.sender]; _principals[msg.sender] = 0; // add logic here } } identity registry this standard is designed specifically for tokenizing bonds. it does not inherently manage information pertaining to bondholders’ identities. however, to enhance compliance with regulatory requirements and improve transparency, an identity registry can be added on top of this standard to store the identity of all authorized investors. by maintaining an identity registry, issuers can ensure that bond tokens issued under the erc7092 standard are transferred only to registered and authorized entities. this practice aligns with regulatory compliance measures and provides a structured way to manage and verify the identity of bondholders. it also helps prevent unauthorized or non-compliant transfers of bond tokens. security considerations implementing this erc requires careful consideration of security risks related to functions approving operators to manage owner’s bonds and functions allowing bond transfers. the use of these functions necessitates robust validation to ensure only the bond owner or approved accounts can call them. copyright copyright and related rights waived via cc0. citation please cite this document as: samuel gwlanold edoumou (@edoumou), "erc-7092: financial bonds [draft]," ethereum improvement proposals, no. 7092, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7092. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-747: wallet_watchasset rpc method ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: interface eip-747: wallet_watchasset rpc method adds a new rpc method that allows websites to prompt users to watch an asset authors dan finlay (@danfinlay), esteban mino (@estebanmino), gavin john (@pandapip1) created 2018-08-13 requires eip-20, eip-1046, eip-1193 table of contents abstract motivation specification wallet_watchasset parameters wallet_watchasset returns erc1046 type legacy erc20 type rationale security considerations server-side request forgery validation fingerprinting copyright abstract this eip standardizes a new wallet-scoped rpc method, wallet_watchasset, to allow a client to suggest a token for the user’s wallet to track. motivation today, one of the major uses of ethereum wallets is to track users’ assets. without this eip, each wallet either needs to pre-load a list of approved assets, or users must manually add assets to their wallet. in the first case, wallets are burdened with both the security of managing this list, as well as the bandwidth of mass polling for known assets on their wallet. in the second case, the user experience is terrible. 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. a new rpc method, wallet_watchasset is added. wallet_watchasset requests that a specified asset be listed to the user’s wallet. it must immediately (i.e. before prompting the user) return true if the request was valid, or error if it was not. the meaning of “listed to the user’s wallet” is dependent on the wallet implementation. a successful call to wallet_watchasset must indicate that the wallet recognized the request and that it contained no issues, but doesn’t indicate whether the user was prompted or whether the asset was actually added to the wallet. wallet_watchasset parameters the wallet_watchasset method takes a single parameter, a watchassetparameters object, which is defined as follows: interface watchassetparameters { type: string; // the asset's interface, e.g. 'erc1046' options: any; } the type string should be the commonly accepted name of the interface implemented by the asset’s contract, e.g. erc1046. defining the global identifiers for different asset types is beyond the scope of this eip. this interface should be extended or modified depending on the asset type. these changes must be specified in separate eips. wallet_watchasset returns wallet_watchasset immediately (i.e. without waiting for user interaction) returns the boolean value true to indicate that the request was recognized (regardless of whether the user was prompted), or errors if the request is invalid. an error might occur in the following circumstances (not comprehensive): the asset type is unrecognized/unsupported the asset was blocked due to an allowlist or denylist (this makes the request ‘invalid’ since the root cause requires developer action) downloading the image failed to load the wallet didn’t load some of the metadata required to display the asset, in order to protect against a potential ssrf attack erc1046 type the format of the options field is: interface erc1046watchassetoptions { { address: string; // the hexadecimal address of the token contract chainid?: number; // the chain id of the asset. if empty, defaults to the current chain id. }; } address is required, and the other fields are optional. address must be the 0x-prefixed checksummed hexadecimal address of the token contract. chainid must be the chain id to which the asset belongs. if the checksum fails, the request must be considered invalid. if the wallet does not recognize the chainid, or the chainid is blank and the wallet does not have a concept of “active” chain, the call must fail. wallet_watchasset must fetch the erc-1046 tokenuri and check the interop field to determine the type of the token. if the parsing fails, or the type is unknown, the rpc call must error. wallet_watchasset should check the name and symbol fields, and the contract address and chainid against a list of well-known tokens. if the name and/or symbol are similar to ones on the list but the chainid/address don’t match, a warning should be presented to the user. the wallet should whitelist and/or blacklist specific ports and schemes to avoid ssrf attacks. legacy erc20 type the format of the options field is: interface erc20watchassetoptions { { address: string; // the hexadecimal address of the token contract chainid?: number; // the chain id of the asset. if empty, defaults to the current chain id. }; } address is required, and the other fields are optional. address must be the 0x-prefixed checksummed hexadecimal address of the token contract. chainid must be the chain id to which the asset belongs. if the checksum fails, the request must be considered invalid. if the wallet does not recognize the chainid, or the chainid is blank and the wallet does not have a concept of “active” chain, the call must fail. wallet_watchasset should check the name and symbol fields, and the contract address and chainid against a list of well-known tokens. if the name and/or symbol are similar to ones on the list but the chainid/address don’t match, a warning should be presented to the user. if possible, it is recommended to instead use the erc1046 type, which supports images and custom metadata. rationale displaying a user’s assets is a basic feature that every modern dapp user expects. most wallets currently either manage their own asset lists, which they store client-side, or they query a centralized api for balances, which reduces decentralization and allows correlating account holders with ip addresses. additionally, refreshing/polling an asset list from the network can be costly, especially on bandwidth-constrained devices. also, maintaining an asset list becomes a political act, provoking harassment and inducing pressure to list obscure assets. automatically listing assets makes assets into a sort of spam mail: users suddenly see new assets that they don’t care about in their wallet. this can be used to send unsolicited information, or even to conduct phishing scams. this phenomenon is already common with airdropped tokens, a major cause of network congestion, because spamming people with new tokens has, so far, been rewarded with increased user attention. when a user is manually adding a asset, they had likely previously learned about it from a website. at that moment, there was a natural alignment of interests, where both parties wanted the user to track the token. this is a natural point to introduce an api to easily allow these parties to collaborate. security considerations server-side request forgery wallets should be careful about making arbitrary requests to urls. as such, it is recommended for wallets to sanitize the uri by whitelisting specific schemes and ports. a vulnerable wallet could be tricked into, for example, modifying data on a locally-hosted redis database. validation wallets should warn users if the symbol or name matches or is similar to another token, to avoid phishing scams. fingerprinting to avoid fingerprinting based on wallet behavior and/or listed assets, the rpc call must return as soon as the user is prompted or an error occurs, without waiting for the user to accept or deny the prompt. copyright copyright and related rights waived via cc0. citation please cite this document as: dan finlay (@danfinlay), esteban mino (@estebanmino), gavin john (@pandapip1), "eip-747: wallet_watchasset rpc method," ethereum improvement proposals, no. 747, august 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-747. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-2335: bls12-381 keystore ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-2335: bls12-381 keystore authors carl beekhuizen created 2019-09-30 discussion link https://github.com/ethereum/eips/issues/2339 requires eip-2333, eip-2334 table of contents simple summary abstract a note on purpose motivation specification password requirements modules decryption key password verification secret decryption description pubkey path uuid version json schema rationale backwards compatibility test cases scrypt test vector pbkdf2 test vector implementation copyright simple summary a json format for the storage and interchange of bls12-381 private keys. abstract a keystore is a mechanism for storing private keys. it is a json file that encrypts a private key and is the standard for interchanging keys between devices as until a user provides their password, their key is safe. a note on purpose this specification is designed not only to be an ethereum 2.0 standard, but one that is adopted by the wider community who have adopted the bls12-381 signature standard. it is therefore important also to consider the needs of the wider industry along with those specific to ethereum. as a part of these considerations, it is the intention of the author that this standard eventually migrate to a more neutral repository in the future. motivation the secure storage and exchange of keys is a vital component of the user experience as people are expected to hold their own keys. it allows users to control access to individual keys and their use by applications. in ethereum 1, the web3 secret storage definition fulfills these requirements, however it is not perfectly suitable for these purposes moving forward. specifically the problems with the existing standard are: the use of keccak256. eth1 keystores use keccak for their checksum, a sensible choice considering its usage within ethereum 1. bls12-381 signatures, keys (eip-2333), and key-storage are inter-chain standards, the establishment and proliferation of which hinges on them being neutral to all chains, something which keccak is not. a lack of abstraction. eth1 keystores are a result of an iterative design process whereby functionality was added and modified as needed without considering how abstractions could simplify the notion of different properties. specification the process of decrypting the secret held within a keystore can be broken down into 3 sub-processes: obtaining the decryption key, verifying the password and decrypting the secret. each process has its own functions which can be selected from as well as parameters required for the function all of which are specified within the keystore file itself. password requirements the password is a string of arbitrary unicode characters. the password is first converted to its nfkd representation, then the control codes (specified below) are stripped from the password and finally it is utf-8 encoded. control codes removal the c0, c1, and delete control codes are not valid characters in the password and should therefore be stripped from the password. c0 are the control codes between 0x00 0x1f (inclusive) and c1 codes lie between 0x80 and 0x9f (inclusive). delete, commonly known as “backspace”, is the utf-8 character 7f which must also be stripped. note that space (sp utf-8 0x20) is a valid character in passwords despite it being a pseudo-control character. modules this standard makes use of the notion of a module which serves to represent, in an abstract sense, the different cryptographic constructions and corresponding parameters for each component of the keystore. the idea being that components can be swapped out without affecting the rest of the specification should the need arise. a module is comprised of a function, which defines which cryptographic construct is being used, params, the parameters required by the function, and message the primary input to the function. decryption key the decryption key is an intermediate key which is used both to verify the user-supplied password is correct, as well as for the final secret decryption. this key is simply derived from the password, the function, and the params specified by thekdf module as per the keystore file. kdf "function" "params" "message" definition pbkdf2-sha-256 "pbkdf2"

"c"
"dklen"
"prf: "hmac-sha256"
"salt"

rfc 2898 scrypt "scrypt"

"dklen"
"n"
"p"
"r"
"salt"

rfc 7914 password verification the password verification step verifies that the password is correct with respect to the checksum.message, cipher.message, and kdf. this is done by appending the cipher.message to the 2nd 16 bytes of the decryption key, obtaining its sha256 hash and verifying whether it matches the checksum.message. inputs decryption_key, the octet string obtained from decryption key process cipher_message, the octet string obtained from keystore file from crypto.cipher.message checksum_message, the octet string obtained from keystore file from crypto.checksum.message outputs valid_password, a boolean value indicating whether the password is valid definitions a[0:3] returns a slice of a including octets 0, 1, 2 a | b is the concatenation of a with b procedure 0. dk_slice = decryption_key[16:32] 1. pre_image = dk_slice | cipher_message 2. checksum = sha256(pre_image) 3. valid_password = checksum == checksum_message 4. return valid_password hash "function" "params" "message" definition sha-256 "sha256" rfc 6234 secret decryption the cipher.function encrypts the secret using the decryption key, thus to decrypt it, the decryption key along with the cipher.function and cipher.params must be used. if the decryption_key is longer than the key size required by the cipher, it is truncated to the correct number of bits. in the case of aes-128-ctr, only the first 16 bytes of the decryption_key are used as the aes key. cipher "function" "params" "message" definition aes-128 counter mode "aes-128-ctr"

"iv"

rfc 3686 description this field is an optional field to help explain the purpose and identify a particular keystores in a user-friendly manner. while this field can, and should, be used to help distinguish keystores from one-another, the description is not necessarily unique. pubkey the pubkey is the public key associated with the the private key secured within the keystore. it is stored here to improve user experience and security which is achieved by not requiring users to enter their password just to obtain their public keys. this field is required if the secret being stored within the keystore is a private key. the encoding of the pubkey is specified in the in the appropriate signature standard (eg. bls12-381 signature standard), but can be seen as a byte-string in the abstract and should be directly compatible with the appropriate signature library. path the path indicates where in the key-tree a key originates from. it is a string defined by eip-2334, if no path is known or the path is not relevant, the empty string, "" indicates this. the path can specify an arbitrary depth within the tree and the deepest node within the tree indicates the depth of the key stored within this file. uuid the uuid provided in the keystore is a randomly generated uuid as specified by rfc 4122. it is used as a 128-bit proxy for referring to a particular set of keys or account. version the version is set to 4. json schema the keystore, at its core, is constructed with modules which allow for the configuration of the cryptographic constructions used password hashing, password verification and secret decryption. each module is composed of: function, params, and message which corresponds with which construction is to be used, what the configuration for the construction is, and what the input is. { "$ref": "#/definitions/keystore", "definitions": { "keystore": { "type": "object", "properties": { "crypto": { "type": "object", "properties": { "kdf": { "$ref": "#/definitions/module" }, "checksum": { "$ref": "#/definitions/module" }, "cipher": { "$ref": "#/definitions/module" } } }, "description": { "type": "string" }, "pubkey": { "type": "string" }, "path": { "type": "string" }, "uuid": { "type": "string", "format": "uuid" }, "version": { "type": "integer" } }, "required": [ "crypto", "path", "uuid", "version" ], "title": "keystore" }, "module": { "type": "object", "properties": { "function": { "type": "string" }, "params": { "type": "object" }, "message": { "type": "string" } }, "required": [ "function", "message", "params" ] } } } rationale the rationale behind the design of this specification is largely the same as that behind the ethereum 1 keystore definition except for the lack of support for keccak (explained in motivation above) and the notion of modules. modules provide a very useful level of abstraction which allow the key-derivation-function, checksum, and cipher to be thought of as instances of the same thing allowing for their substitution with minimal effort. the version is set to 4 to prevent collisions with the existing ethereum keystore standard. backwards compatibility this specification is not backwards compatible with the existing keystore standard due to the lack of keccak256 checksums as explained above. while this format is capable of supporting keccak checksums via the checksum module, it would defeat the purpose of this standard to include it as this standard could no longer be considered neutral with respect to other projects in the industry. test cases scrypt test vector password "𝔱𝔢𝔰𝔱𝔭𝔞𝔰𝔰𝔴𝔬𝔯𝔡🔑" encoded password: 0x7465737470617373776f7264f09f9491 secret 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f { "crypto": { "kdf": { "function": "scrypt", "params": { "dklen": 32, "n": 262144, "p": 1, "r": 8, "salt": "d4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3" }, "message": "" }, "checksum": { "function": "sha256", "params": {}, "message": "d2217fe5f3e9a1e34581ef8a78f7c9928e436d36dacc5e846690a5581e8ea484" }, "cipher": { "function": "aes-128-ctr", "params": { "iv": "264daa3f303d7259501c93d997d84fe6" }, "message": "06ae90d55fe0a6e9c5c3bc5b170827b2e5cce3929ed3f116c2811e6366dfe20f" } }, "description": "this is a test keystore that uses scrypt to secure the secret.", "pubkey": "9612d7a727c9d0a22e185a1c768478dfe919cada9266988cb32359c11f2b7b27f4ae4040902382ae2910c15e2b420d07", "path": "m/12381/60/3141592653/589793238", "uuid": "1d85ae20-35c5-4611-98e8-aa14a633906f", "version": 4 } pbkdf2 test vector password "𝔱𝔢𝔰𝔱𝔭𝔞𝔰𝔰𝔴𝔬𝔯𝔡🔑" encoded password: 0x7465737470617373776f7264f09f9491 secret 0x000000000019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f { "crypto": { "kdf": { "function": "pbkdf2", "params": { "dklen": 32, "c": 262144, "prf": "hmac-sha256", "salt": "d4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3" }, "message": "" }, "checksum": { "function": "sha256", "params": {}, "message": "8a9f5d9912ed7e75ea794bc5a89bca5f193721d30868ade6f73043c6ea6febf1" }, "cipher": { "function": "aes-128-ctr", "params": { "iv": "264daa3f303d7259501c93d997d84fe6" }, "message": "cee03fde2af33149775b7223e7845e4fb2c8ae1792e5f99fe9ecf474cc8c16ad" } }, "description": "this is a test keystore that uses pbkdf2 to secure the secret.", "pubkey": "9612d7a727c9d0a22e185a1c768478dfe919cada9266988cb32359c11f2b7b27f4ae4040902382ae2910c15e2b420d07", "path": "m/12381/60/0/0", "uuid": "64625def-3331-4eea-ab6f-782f3ed16a83", "version": 4 } implementation implementations exist in the following languages: python3 typescript go copyright copyright and related rights waived via cc0. citation please cite this document as: carl beekhuizen , "erc-2335: bls12-381 keystore [draft]," ethereum improvement proposals, no. 2335, september 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2335. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-6682: nft flashloans ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-6682: nft flashloans minimal interface for erc-721 nft flashloans authors out.eth (@outdoteth) created 2023-03-12 discussion link https://ethereum-magicians.org/t/eip-6682-nft-flashloans/13294 requires eip-20, eip-721, eip-3156 table of contents abstract motivation specification contract interface rationale backwards compatibility reference implementation security considerations copyright abstract this standard is an extension of the existing flashloan standard (erc-3156) to support erc-721 nft flashloans. it proposes a way for flashloan providers to lend nfts to contracts, with the condition that the loan is repaid in the same transaction along with some fee. motivation the current flashloan standard, erc-3156, only supports erc-20 tokens. erc-721 tokens are sufficiently different from erc-20 tokens that they require an extension of this existing standard to support them. an nft flash loan could be useful in any action where nft ownership is checked. for example, claiming airdrops, claiming staking rewards, or taking an in-game action such as claiming farmed resources. 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. contract interface pragma solidity ^0.8.19; interface ierc6682 { /// @dev the address of the token used to pay flash loan fees. function flashfeetoken() external view returns (address); /// @dev whether or not the nft is available for a flash loan. /// @param token the address of the nft contract. /// @param tokenid the id of the nft. function availableforflashloan(address token, uint256 tokenid) external view returns (bool); } the flashfeetoken function must return the address of the token used to pay flash loan fees. if the token used to pay the flash loan fees is eth then flashfeetoken must return address(0). the availableforflashloan function must return whether or not the tokenid of token is available for a flashloan. if the tokenid is not currently available for a flashloan availableforflashloan must return false instead of reverting. implementers must also implement ierc3156flashlender. rationale the above modifications are the simplest possible additions to the existing flashloan standard to support nfts. we choose to extend as much of the existing flashloan standard (erc-3156) as possible instead of creating a wholly new standard because the flashloan standard is already widely adopted and few changes are required to support nfts. in most cases, the handling of fee payments will be desired to be paid in a separate currency to the loaned nfts because nfts themselves cannot always be fractionalized. consider the following example where the flashloan provider charges a 0.1 eth fee on each nft that is flashloaned; the interface must provide methods that allow the borrower to determine the fee rate on each nft and also the currency that the fee should be paid in. backwards compatibility this eip is fully backwards compatible with erc-3156 with the exception of the maxflashloan method. this method does not make sense within the context of nfts because nfts are not fungible. however it is part of the existing flashloan standard and so it is not possible to remove it without breaking backwards compatibility. it is recommended that any contract implementing this eip without the intention of supporting erc-20 flashloans should always return 1 from maxflashloan. the 1 reflects the fact that only one nft can be flashloaned per flashloan call. for example: function maxflashloan(address token) public pure override returns (uint256) { // if a contract also supports flash loans for erc20 tokens then it can // return some value here instead of 1 return 1; } reference implementation // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.19; import "../interfaces/ierc20.sol"; import "../interfaces/ierc721.sol"; import "../interfaces/ierc3156flashborrower.sol"; import "../interfaces/ierc3156flashlender.sol"; import "../interfaces/ierc6682.sol"; contract exampleflashlender is ierc6682, ierc3156flashlender { uint256 internal _feepernft; address internal _flashfeetoken; constructor(uint256 feepernft_, address flashfeetoken_) { _feepernft = feepernft_; _flashfeetoken = flashfeetoken_; } function flashfeetoken() public view returns (address) { return _flashfeetoken; } function availableforflashloan(address token, uint256 tokenid) public view returns (bool) { // return if the nft is owned by this contract try ierc721(token).ownerof(tokenid) returns (address result) { return result == address(this); } catch { return false; } } function flashfee(address token, uint256 tokenid) public view returns (uint256) { return _feepernft; } function flashloan(ierc3156flashborrower receiver, address token, uint256 tokenid, bytes calldata data) public returns (bool) { // check that the nft is available for a flash loan require(availableforflashloan(token, tokenid), "ierc6682: nft not available for flash loan"); // transfer the nft to the borrower ierc721(token).safetransferfrom(address(this), address(receiver), tokenid); // calculate the fee uint256 fee = flashfee(token, tokenid); // call the borrower bool success = receiver.onflashloan(msg.sender, token, tokenid, fee, data) == keccak256("erc3156flashborrower.onflashloan"); // check that flashloan was successful require(success, "ierc6682: flash loan failed"); // check that the nft was returned by the borrower require(ierc721(token).ownerof(tokenid) == address(this), "ierc6682: nft not returned by borrower"); // transfer the fee from the borrower ierc20(flashfeetoken()).transferfrom(msg.sender, address(this), fee); return success; } function maxflashloan(address token) public pure override returns (uint256) { // if a contract also supports flash loans for erc20 tokens then it can // return some value here instead of 1 return 1; } function onerc721received(address, address, uint256, bytes memory) public returns (bytes4) { return this.onerc721received.selector; } } security considerations it’s possible that the flashfeetoken method could return a malicious contract. borrowers who intend to call the address that is returned from the flashfeetoken method should take care to ensure that the contract is not malicious. one way they could do this is by verifying that the returned address from flashfeetoken matches that of a user input. needs discussion. copyright copyright and related rights waived via cc0. citation please cite this document as: out.eth (@outdoteth), "erc-6682: nft flashloans [draft]," ethereum improvement proposals, no. 6682, march 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6682. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3520: transaction destination opcode ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-3520: transaction destination opcode authors alex papageorgiou (@alex-ppg) created 2021-04-16 discussion link https://ethereum-magicians.org/t/eip-3520-transaction-destination-opcode/6058 requires eip-3508 table of contents simple summary abstract motivation specification entrypoint (0x4a) rationale authcall (0xf7) interaction naming conventions instruction address space gas cost dependency on eip-3508 backwards compatibility test cases security considerations introspective contracts caller discrimination contract creation behaviour copyright simple summary provide access to the original recipient of a transaction. abstract this eip introduces the following evm instruction: entrypoint. this instruction is meant to provide access to the original recipient of the transaction, the to address, enabling new ways of introspection to be applied in conjunction with eip-3508. motivation it is undeniable that smart contracts are becoming more interconnected than ever. up until this point, smart contracts have entirely relied on compliant interfaces and introspection to introduce a new step in the call chain of a complex multi-contract interaction. however, this presents a forwards-only approach which limits the types of interactions that can manifest. the purpose of this eip is to provide a way via which a contract is able to identify the entry-point of a transaction on the blockchain and deduce what was the original intention of the transaction by applying introspection on the original transaction data itself. this eip enables the development of new types of smart contracts as it can open new pathways for eip-721 nfts and eip-20 tokens to detect which action their transaction is part of, such as detecting a liquidity provision to a decentralized exchange or a loan within a collateralized lending protocol. specification entrypoint (0x4a) the entrypoint instruction uses 0 stack arguments and pushes the original to member of the transaction onto the stack. the address yielded by the instruction is a 160-bit value padded to 256-bits. the operation costs g_base to execute, similarly to origin (0x32). the address returned by the entrypoint opcode will be equivalent to the to address parameter specified in the nearest authcall up the stack. if there is no authcall in the stack then entrypoint will retrieve the original transaction’s to field. rationale authcall (0xf7) interaction the eip-3074 introduced a new call instruction called authcall (0xf7) that will replace a transaction’s origin (0x32) with the context variable authorized. the intention of authcall is to prevent discrimination between smart contracts and eoas which origin initially facilitated. the entrypoint opcode by itself re-introduces discrimination into the system as it indirectly allows one to evaluate whether the smart contract code being executed is done so by an eoa by validating that entrypoint == address where address (0x30) retrieves the currently executing account address. therefore, it is sensible also replace the values retrieved by the entrypoint opcode to the target of an authcall. this interaction ensures full compatibility with eip-3074 and ensures that no form of discrimination is introduced back into the system by this eip. naming conventions the entrypoint instruction came to be by defining a sensible name that immediately and clearly depicts what it is meant to achieve by signaling the first interaction of a particular call, i.e. the entry-point. instruction address space equivalent to eip-3508. gas cost the opcode entrypoint (0x4a) essentially performs the same thing as the opcode origin (0x32) and thus shares the exact same gas cost. dependency on eip-3508 the entrypoint (0x4a) instruction alone has no perceivable benefit as it can be replaced by the authcall (0xf7) instruction and as such should solely be introduced to the system in conjunction with the origindata* opcodes defined in eip-3508. backwards compatibility the eip does not alter or adjust existing functionality provided by the evm and as such, no known issues exist. test cases todo. security considerations introspective contracts the entrypoint instruction allows the association of the origindataload and origindatacopy values with a particular smart contract address and interface, enabling introspection to be applied based on the function signature invoked and the arguments provided to reliably deduce the call-path via which a particular smart contract was invoked and allowing a more granular level of interaction to be defined in such special cases. however, this type of introspection should solely be applied on pre-approved contracts rather than user-defined ones as the value stemming from this type of introspection entirely relies on a contract’s code immutability and proper function, both of which a user supplied contract can easily bypass. caller discrimination the instructions of this eip should not be utilized as a way to discriminate between eoa callers and smart contracts, as this type of differentiation can be broken by an authcall as defined in the specification chapter. contract creation behaviour the behaviour of the entrypoint opcode during a contract creation will result in the opcode yielding the zero-address as the first address interacted with in the transaction. this should be taken into account by contract implementations in a similar fashion to how ecrecover invalid signatures are handled to prevent software misbehaviours from arising. copyright copyright and related rights waived via cc0. citation please cite this document as: alex papageorgiou (@alex-ppg), "eip-3520: transaction destination opcode [draft]," ethereum improvement proposals, no. 3520, april 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3520. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. security advisory [insecurely configured geth can make funds remotely accessible] | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search security advisory [insecurely configured geth can make funds remotely accessible] posted by jutta steiner on august 29, 2015 security insecurely configured ethereum clients with no firewall and unlocked accounts can lead to funds being accessed remotely by attackers. affected configurations: issue reported for geth, though all implementations incl. c++ and python can in principle display this behavior if used insecurely; only for nodes which leave the json-rpc port open to an attacker (this precludes most nodes on internal networks behind nat), bind the interface to a public ip, and simultaneously leave accounts unlocked at startup. likelihood: low severity: high impact: loss of funds related to wallets imported or generated in clients details: it’s come to our attention that some individuals have been bypassing the built-in security that has been placed on the json-rpc interface. the rpc interface allows you to send transactions from any account which has been unlocked prior to sending a transaction and will stay unlocked for the entirety of the the session. by default, rpc is disabled, and by enabling it it is only accessible from the same host on which your ethereum client is running. by opening the rpc to be accessed by anyone on the internet and not including a firewall rules, you open up your wallet to theft by anybody who knows your address in combination with your ip. effects on expected chain reorganisation depth: none remedial action taken by ethereum: eth rc1 will be fully secure by requiring explicit user-authorisation for any potentially remote transaction. later versions of geth may support this functionality. proposed temporary workaround: only run the default settings for each client and when you do make changes understand how these changes impact your security. note: this is not a bug, but a misuse of json-rpc. advisory: never enable json-rpc interface on an internet-accessible machine without a firewall policy in place to block the json-rpc port (default: 8545). eth: use rc1 or later. geth: use the safe defaults, and know security implications of the options. --rpcaddr "127.0.0.1". this is the default value to only allow connections originating on the local computer; remote rpc connections are disabled --unlock. this parameter is used to unlock accounts at startup to aid in automation. by default, all accounts are locked previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-1592: address and erc20-compliant transfer rules ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1592: address and erc20-compliant transfer rules authors cyril lapinte , laurent aapro created 2018-11-09 discussion link https://github.com/ethereum/eips/issues/1597 table of contents simple summary abstract motivation specification rule interface withrules interface withrules implementation integration history copyright simple summary we propose a standard and an interface to define transfer rules, in the context of erc20 tokens and possibly beyond. a rule can act based on sender, destination and amount, and is triggered (and rejects the transfer) according to any required business logic. to ease rule reusability and composition, we also propose an interface and base implementation for a rule engine. abstract this standard proposal should answer the following challenges: enable integration of rules with interacting platforms such as exchanges, decentralized wallets and dapps. externale code and storage, improve altogether reusability, gas costs and contracts’ memory footprint. highlight contract behavior and its evolution, in order to ease user interaction with such contract. if these challenges are answered, this proposal will provide a unified basis for transfer rules and hopefully address the transfer restriction needs of other eips as well, e.g. eip-902, eip-1066 and eip-1175. this document proposes specifications for a standard of transfer rules and interfaces to both the rules and the rule engine, which was made to be inherited by a token, but may have a much broader scope in the authors’ opinion. the last section of this document illustrates the proposal with a rule template and links to rule implementations. motivation erc20 was designed as a standard interface allowing any token on ethereum to be handled by other applications: from wallets to decentralized exchanges. this has been extremely powerful, but future developments in the industry of tokenization are bringing new challenges. for example it is already hard to know exactly why an erc20 transfer failed, and it will become even harder when many tokens add their own transfer rules to the mix; we propose that it should be trivial to determine before a tx is sent, whether the transfer should turn out valid or invalid, and why (unless conditions change in the meantime obviously). on the other hand, if the rules were changed, it should also be easily detected, so that the interacting party knows it must adjust its expectations or model. specification we define below an interface for a rule. rules are meant to be as simple as possible, to limit gas expenditure, since that logic will be executed on every transfer. another reason for keeping rules simple and short, and strive for atomicity, is to facilitate both composition and interpretation of rejected transfers. by knowing which rule was triggered, we obtain a clear picture of the reason for rejection. the engine we propose executes all the rules defined by its owner, on every transfer and it is easy to add and remove rules individually, although we have chosen to use quite a raw rule update method, to save on deployment costs, which are often tight when it comes to token smart contracts. rules are deployed on the blockchain as individual smart contracts, and called upon by the rule engine they were attached to. but any third party, for example an exchange preparing a cashout for a customer, can very cheaply query the rule engine of the token, or a single rule directly, to verify the validity of a transfer before execution, so as to never get a rejected transaction. rule interface irule interface should provide a way to validate if an address or a transfer is valid. if one of these two methods is not applicable, it can simply be made to return true systematically. if any parameter of istransfervalid is not needed, its name should be commented out with /* */. pragma solidity ^0.4.25; interface irule { function isaddressvalid(address _address) external view returns (bool); function istransfervalid(address _from, address _to, uint256 _amount) external view returns (bool); } withrules interface withrules interface describes the integration of rules to a rule engine. developers may choose to not implement this interface if their code will only deal with one rule, or if it is not desirable to update the rules. the rules ordering must be thought through carefully. rules which are cheaper to validate or have a higher chance to break should be put first to reduce global gas expenditure, then business logic should guide the ordering of rules. that is why rules for a given context should be defined as a whole and not individually. pragma solidity ^0.4.25; import "./irule.sol"; interface iwithrules { function rulelength() public view returns (uint256); function rule(uint256 _ruleid) public view returns (irule); function validateaddress(address _address) public view returns (bool); function validatetransfer(address _from, address _to, uint256 _amount) public view returns (bool); function definerules(irule[] _rules) public; event rulesdefined(uint256 count); } withrules implementation we also propose a simple implementation of the rule engine, available here. it has been kept minimal both to save on gas costs on each transfer, and to reduce the deployment cost overhead for the derived smart contract. on top of implementing the interface above, this engine also defines two modifiers (whenaddressrulesarevalidand whentransferrulesarevalid), which can be used throughout the token contract to restrict transfer(), transferfrom and any other function that needs to respect either a simple whitelist or complex transfer rules. integration to use rules within a token is as easy as having the token inherit from withrules, then writing rules according to the irule interface and deploying each rule individually. the token owner can then use definerules() to attach all rules in the chosen order, within a single transaction. below is a template for a rule. import "../interface/irule.sol"; contract templaterule is irule { // state vars for business logic constructor(/* arguments for init */) public { // initializations } function isaddressvalid(address _from) public view returns (bool) { boolean isvalid; // business logic return isvalid; } function istransfervalid( address _from, address _to, uint256 _amount) public view returns (bool) { boolean isvalid; // business logic return isvalid; } } ** notes ** the mps (mt pelerin’s share) token is the current live implementation of this standard. other implementations may be written with different trade-offs: from gas savings to improved security. example of rules implementations yesno rule: trivial rule used to demonstrate both a rule and the rule engine. freeze rule: this rule allows to prevent any transfer of tokens to or from chosen addresses. a smart blacklist. lock rule: define a global transfer policy preventing either sending or receiving tokens within a period of time. exceptions may be granted to some addresses by the token admin. a smart whitelist. user kyc rule: rule example relying on an existing whitelist to assert transfer and addresses validity. it is a good example of a rule that completely externalizes it’s tasks. example implementations are available at mt pelerin bridge protocol rules implementation mt pelerin token with rules history historical links related to this standard: the first regulated tokenized share issued by mt pelerin (mps token) is using an early version of this proposal: https://www.mtpelerin.com/blog/world-first-tokenized-shares the rule engine was updated several times, after the token issuance and during the tokensale, to match changing business and legal requirements, showcasing the solidity and flexibility of the rule engine. copyright copyright and related rights waived via cc0. external references outside this repository will have their own specific copyrights. citation please cite this document as: cyril lapinte , laurent aapro , "erc-1592: address and erc20-compliant transfer rules [draft]," ethereum improvement proposals, no. 1592, november 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1592. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. toward a 12-second block time | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search toward a 12-second block time posted by vitalik buterin on july 11, 2014 research & development one of the annoyances of the blockchain as a decentralized platform is the sheer length of delay before a transaction gets finalized. one confirmation in the bitcoin network takes ten minutes on average, but in reality due to statistical effects when one sends a transaction one can only expect a confirmation within ten minutes 63.2% of the time; 36.8% of the time it will take longer than ten minutes, 13.5% of the time longer than twenty minutes and 0.25% of the time longer than an hour. because of fine technical points involving finney attacks and sub-50% double spends, for many use cases even one confirmation is not enough; gambling sites and exchanges often need to wait for three to six blocks to appear, often taking over an hour, before a deposit is confirmed. in the time before a transaction gets into a block, security is close to zero; although many miners refuse to forward along transactions that conflict with transactions that had already been sent earlier, there is no economic necessity for them to do so (in fact quite the contrary), and some don't, so reversing an unconfirmed transaction is possible with about a 10-20% success rate. in many cases, this is fine; if you pay for a laptop online, and then manage to yank back the funds five minutes later, the merchant can simply cancel the shipping; online subscription services work the same way. however, in the context of some in-person purchases and digital goods purchases, it is highly inconvenient. in the case of ethereum, the inconvenience is greater; we are trying to be not just a currency, but rather a generalized platform for decentralized applications, and especially in the context of non-financial apps people tend to expect a much more rapid response time. thus, for our purposes, having a blockchain that is faster than 10 minutes is critical. however, the question is, how low can we go, and if we go too low does that destabilize anything? overview of mining first off, let us have a quick overview of how mining works. the bitcoin blockchain is a series of blocks, with each one pointing to (ie. containing the hash of) the previous. each miner in the network attempts to produce blocks by first grabbing up the necessary data (previous block, transactions, time, etc), building up the block header, and then continually changing a value called the nonce until the nonce satisfies a function called a "proof of work condition" (or "mining algorithm"). this algorithm is random and usually fails; on average, in bitcoin the network needs to collectively make about 1020 attempts before a valid block is found. once some random miner finds a block that is valid (ie. it points to a valid previous block, its transactions and metadata are valid, and its nonce satisfies the pow condition), then that block is broadcast to the network and the cycle begins again. as a reward, the miner of that block gets some quantity of coins (25 btc in bitcoin) as a reward. the "score" of a block is defined in a simplified model as the number of blocks in the chain going back from it all the way to the genesis (formally, it's the total mining difficulty, so if the difficulty of the proof of work condition increases blocks created under this new more stringent condition count for more). the block that has the highest score is taken to be "truth". a subtle, but important, point is that in this model the incentive for miners is always to mine on the block with the highest score, because the block with the highest score is what users ultimately care about, and there are never any factors that make a lower-score block better. if we fool around with the scoring model, then if we are not careful this might change; but more on this later. we can model this kind of network thus: however, the problems arise when we take into account the fact that network propagation is not instant. according to a 2013 paper from decker and wattenhofer in zurich, once a miner produces a block on average it takes 6.5 seconds for the block to reach 50% of nodes, 40 seconds for it to reach 95% of nodes and the mean delay is 12.6 seconds. thus, a more accurate model might be: this gives rise to the following problem: if, at time t = 500, miner m mines a block b' on top of b (where "on top of" is understood to mean "pointing to as the previous block in the chain"), then miner n might not hear about the block until time t = 510, so until t = 510 miner n will still be mining on b. if miner b finds a block in that interval, then the rest of the network will reject miner b's block because they already saw miner m's block which has an equal score: stales, efficiency and centralization so what's wrong with this? actually, two things. first, it weakens the absolute strength of the network against attacks. at a block time of 600 seconds, as in bitcoin, this is not an issue; 12 seconds is a very small amount of time, and decker and wattenhofer estimate the total stale rate as being around 1.7%. hence, an attacker does not actually need 50.001% of the network in order to launch a 51% attack; if the attacker is a single node, they would only need 0.983 / 1 + 0.983 = 49.5%. we can estimate this via a mathematical formula: if transit time is 12 seconds, then after a block is produced the network will be producing stales for 12 seconds before the block propagates, so we can assume an average of 12 / 600 = 0.02 stales per valid block or a stale rate of 1.97%. at 60 seconds per block, however, we get 12 / 60 = 0.2 stales per valid block or a stale rate of 16.67%. at 12 seconds per block, we get 12 / 12 = 1 stale per valid block, or a stale rate of 50%. thus, we can see the network get substantially weaker against attacks. however, there is also another negative consequence of stale rates. one of the more pressing issues in the mining ecosystem is the problem of mining centralization. currently, most of the bitcoin network is split up into a small number of "mining pools", centralized constructions where miners share resources in order to receive a more even reward, and the largest of these pools has for months been bouncing between 33% and 51% of network hashpower. in the future, even individual miners may prove threatening; right now 25% of all new bitcoin mining devices are coming out of a single factory in shenzhen, and if the pessimistic version of my economic analysis proves correct that may eventually morph into 25% of all bitcoin miners being in a single factory in shenzhen. so how do stale rates affect centralization? the answer is a clever one. suppose that you have a network with 7000 pools with 0.01% hashpower, and one pool with 30% hashpower. 70% of the time, the last block is produced by one of these miners, and the network hears about it in 12 seconds, and things are somewhat inefficient but nevertheless fair. 30% of the time, however, it is the 30% hashpower mining pool that produced the last block; thus, it "hears" about the block instantly and has a 0% stale rate, whereas everyone else still has their full stale rate. because our model is still pretty simple, we can still do some math on an approximation in closed form. assuming a 12 second transit time and a 60-second block time, we have a stale rate of 16.67% as described above. the 30% mining pool will have a 0% stale rate 30% of the time, so its efficiency multiplier will be 0.833 * 0.7 + 1 * 0.3 = 0.8831, whereas everyone else will have an efficiency multiplier of 0.833; that's a 5.7% efficiency gain which is pretty economically significant especially for mining pools where the difference in fees is only a few percent either way. thus, if we want a 60 second block time, we need a better strategy. ghost the beginnings of a better approach come from a paper entitled "fast money grows on trees, not chains", published by aviv zohar and yonatan sompolinsky in december 2013. the idea is that even though stale blocks are not currently counted as part of the total weight of the chain, they could be; hence they propose a blockchain scoring system which takes stale blocks into account even if they are not part of the main chain. as a result, even if the main chain is only 50% efficient or even 5% efficient, an attacker attempting to pull off a 51% attack would still need to overcome the weight of the entire network. this, theoretically, solves the efficiency issue all the way down to 1-second block times. however, there is a problem: the protocol, as described, only includes stales in the scoring of a blockchain; it does not assign the stales a block reward. hence, it does nothing to solve the centralization problem; in fact, with a 1-second block time the most likely scenario involves the 30% mining pool simply producing every block. of course, the 30% mining pool producing every block on the main chain is fine, but only if the blocks off chain are also fairly rewarded, so the 30% mining pool still collects not much more than 30% of the revenue. but for that rewarding stales will be required. now, we can't reward all stales always and forever; that would be a bookkeeping nightmare (the algorithm would need to check very diligently that a newly included uncle had never been included before, so we would need an "uncle tree" in each block alongside the transaction tree and state tree) and more importantly it would make double-spends cost-free. thus, let us construct our first protocol, single-level ghost, which does the minimal thing and takes uncles only up to one level (this is the algorithm used in ethereum up to now): every block must point to a parent (ie. previous block), and can also include zero or more uncles. an "uncle" is defined as a block with a valid header (the block itself need not be valid, since we only care about its proof-of-work) which is the child of the parent of the parent of the block but not the parent (ie. the standard definition of "uncle" from genealogy that you learned at age 4). a block on the main chain gets a reward of 1. when a block includes an uncle, the uncle gets a reward of 7/8 and the block including the uncle gets a reward of 1/16. the score of a block is zero for the genesis block, otherwise the score of the parent plus the difficulty of the block multiplied by one plus the number of included uncles. thus, in the graphical blockchain example given above, we'll instead have something like this: here, the math gets more complex, so we'll make some intuitive arguments and then take the lazy approach and simulate the whole thing. the basic intuitive argument is this: in the basic mining protocol, for the reasons we described above, the stale rate is roughly t/(t+t) where t is the transit time and t is the block interval, because t/t of the time miners are mining on old data. with single-level ghost, the failure condition changes from mining one stale to mining two stales in a row (since uncles can get included but relatives with a divergence of 2 or higher cannot), so the stale rate should be (t/t)^2, ie. about 2.7% instead of 16.7%. now, let's use a python script to test that theory: ### printing results ### 1 1.0 10 10.2268527074 25 25.3904084273 5 4.93500893242 15 14.5675475882 total blocks produced: 16687 total blocks in chain: 16350 efficiency: 0.979804638341 average uncles: 0.1584242596 length of chain: 14114 block time: 70.8516366728 the results can be parsed as follows. the top five numbers are a centralization indicator; here, we see that a miner with 25% hashpower gets 25.39x as much reward as a miner with 1% hashpower. the efficiency is 0.9798 meaning that 2.02% of all blocks are not included at all, and there are 0.158 uncles per block; hence, our intuitions about a ~16% stale rate without uncle inclusion and 2.7% with uncle inclusion are confirmed almost exactly. note that the actual block time is 70.85s because even though there is a valid proof of work solution every 60s, 2% of them are lost and 14% of them make it into only the next block as an uncle, not into the main chain. now, there is a problem here. the original authors of the ghost paper did not include uncle/stale rewards, and although i believe it is a good idea to deviate from their prescription for the reasons i described above, they did not do so for a reason: it makes the economic analysis more uncomfortable. specifically, when only the main chain gets rewarded there is an unambiguous argument why it's always worth it to mine on the head and not some previous block, namely the fact that the only thing that conceivably differentiates any two blocks is their score and higher score is obviously better than lower score, but once uncle rewards are introduced there are other factors that make things somewhat tricky. specifically, suppose that the main chain has its last block m (score 502) with parent l (score 501) with parent k (score 500). also suppose that k has two stale children, both of which were produced after m so there was no chance for them to be included in m as uncles. if you mine on m, you would produce a block with score 502 + 1 = 503 and reward 1, but if you mine on l you would be able to include k's children and get a block with score 501 + 1 + 2 = 504 and reward 1 + 0.0625 * 2 = 1.125. additionally, there is a selfish-mining-esque attack against single-level ghost. the argument is as follows: if a mining pool with 25% hashpower were not to include any other blocks, then in the short term it would hurt itself because it would no longer receive the 1/16x nephew reward but it would hurt others more. because in the long-term mining is a zero-sum game since the block time rebalances to keep issuance constant, this means that not including uncles might actually be a dominant strategy, so centralization concerns are not entirely gone (specifically, they still remain 30% of the time). additionally, if we decide to crank up the speed further, say to a 12 second target block time, single-level is just not good enough. here's a result with those statistics: ### printing results ### 1 1.0 10 10.4567533177 15 16.3077390517 5 5.0859101624 25 29.6409432377 total blocks produced: 83315 total blocks in chain: 66866 efficiency: 0.802568565084 average uncles: 0.491246459555 length of chain: 44839 block time: 22.3020138719 18% centralization gain. thus, we need a new strategy. a new strategy the first idea i tried about one week ago was requiring every block to have five uncles; this would in a sense decentralize the production of each block further, ensuring that no miner had a clear advantage in making the next block. since the math for that is pretty hopelessly intractable (well, if you try hard at it for months maybe you could come up with something involving nested poisson processes and combinatorical generating functions, but i'd rather not), here's the sim script. note that there are actually two ways you can do the algorithm: require the parent to be the lowest-hash child of the grandparent, or require the parent to be the highest-score child of the grandparent. the first way (to do this yourself, modify line 56 to if newblock["id"] > self.blocks[self.head]["id"]:, we get this: ### printing results ### 1 1.0 10 9.59485744106 25 24.366668248 5 4.82484937616 15 14.0160823568 total blocks produced: 8033 total blocks in chain: 2312 efficiency: 0.287812772314 average uncles: 385.333333333 length of chain: 6 block time: 13333.3333333 ooooops! well, let's try the highest-score model: ### printing results ### 1 1.0 10 9.76531271652 15 14.1038046954 5 5.00654546181 25 23.9234131003 total blocks produced: 7989 total blocks in chain: 6543 efficiency: 0.819001126549 average uncles: 9.06232686981 length of chain: 722 block time: 110.8033241 so here we have a very counterintuitive result: the 25% hashpower mining pool gets only 24x as much as a 1% hashpower pool. economic sublinearity is a cryptoeconomic holy grail, but unfortunately it is also somewhat of a perpetual motion machine; unless you rely on some specific thing that people have a certain amount of (eg. home heating demand, unused cpu power), there is no way to get around the fact even if you come up with some clever sublinear concoction an entity with 25x as much power going in will at the very least be able to pretend to be 25 separate entities and thus claim a 1x reward. thus, we have an unambiguous (okay, fine, 99 point something percent confidence) empirical proof that the 25x miners are acting suboptimally, meaning that the optimal strategy in this environment is not to always mine the block with the highest score. the reasoning here is this: if you mine on a block that has the highest score, then there is some chance that someone else will discover a new uncle one level back, and then mine a block on top of that, creating a new block at the same level as your block but with a slightly higher score and leaving you in the dust. however, if you try to be one of those uncles, then the highest-score block at the next level will certainly want to include you, so you will get the uncle reward. the presence of one non-standard strategy strongly suggests the existence of other, and more exploitative, non-standard strategies, so we're not going this route. however, i chose to include it in the blog post to show an example of what the dangers are. so what is the best way forward? as it turns out, it's pretty simple. go back to single level ghost, but allow uncles to come from up to 5 blocks back. hence, the child of a parent of a parent (hereinafter, -2,+1-ancestor) is a valid uncle, a -3,+1-ancestor is a valid uncle, as is a -4,+1-ancestor and a -5,+1-ancestor, but a -6,+1-ancestor or a -4,+2-ancestor (ie. c(c(p(p(p(p(head)))))) where no simplification is possible) is not. additionally, we increase the uncle reward to 15/16, and cut the nephew reward to 1/32. first, let's make sure that it works under standard strategies. in the ghost sim script, set uncle_depth to 4, pow_solution_time to 12, transit_time to 12, uncle_reward_coeff to 15/16 and nephew_reward_coeff to 1/32 and see what happens: ### printing results ### 1 1.0 10 10.1329810896 25 25.6107014231 5 4.96386947539 15 15.0251826297 total blocks produced: 83426 total blocks in chain: 77306 efficiency: 0.926641574569 average uncles: 0.693116362601 length of chain: 45659 block time: 21.901487111 completely reasonable all around, although note that the actual block time is 21s due to inefficiency and uncles rather than the 12s we targeted. now, let's try a few more trials for enlightenment and fun: uncle_reward_coeff = 0.998, nephew_reward_coeff = 0.001 lead to the 25% mining pool getting a roughly 25.3x return, and setting uncle_reward_coeff = 7/8 and nephew_reward_coeff = 1/16 leads to the 25% mining pool getting a 26.26% return. obviously setting the uncle_reward_coeff all the way to zero would negate the benefit completely, so it's good to have it be as close to one as possible, but if it's too close to one than there's no incentive to include uncles. uncle_reward_coeff = 15/16 seems to be a fair middle ground, giving the 25% miner a 2.5% centralization advantage allowing uncles going back 50 blocks, surprisingly, has fairly little substantial efficiency gain. the reason is that the dominant weakness of -5,+1 ghost is the +1, not the -5, ie. stale c(c(p(p(..p(head)..)))) blocks are the problem. as far as centralization goes, with 0.998/0.001 rewards it knocks the 25% mining pool's reward down to essentially 25.0x. with 15/16 and 1/32 rewards there is no substantial gain over the -4,+1 approach. allowing -4,+3 children increases efficiency to effectively 100%, and cuts centralization to near-zero assuming 0.998/0.001 rewards and has negligible benefit assuming 15/16 and 1/32 rewards. if we reduce the target block time to 3 seconds, efficiency goes down to 66% and the 25% miner gets a 31.5x return (ie. 26% centralization gain). if we couple this with a -50,+1 rule, the effect is negligible (25% -> 31.3x), but if we use a -4,+3 rule efficiency goes up to 83% and the 25% miner only gets a 27.5x return (the way to add this to the sim script is to add after line 65 for c2 in self.children.get(c, {}): u[c2] = true for a -n,+2 rule and then similarly nest down one level further for -n,+3). additionally, the actual block time in all three of these scenarios is around 10 seconds. if we reduce the target block time to 6 seconds, then we get an actual block time of 15 seconds and the efficiency is 82% and the 25% miner gets 26.8x even without improvements. now, let's look at the other two risks of limited ghost that we discussed above: the non-head dominant strategy and the selfish-mining attack. note that there are actually two non-head strategies: try to take more uncles, and try to be an uncle. trying to take more uncles was useful in the -2,+1 case, and trying to be an uncle was useful in the cas of my abortive mandatory-5-uncles idea. trying to be an uncle is not really useful when multiple uncles are not required, since the reason why that alternative strategy worked in the mandatory-5-uncle case is that a new block is useless for further mining without siblings. thus, the only potentially problematic strategy is trying to include uncles. in the one-block case, it was a problem, but here is it not because most uncles that can be included after n blocks can also be included after n+1 blocks, so the practical extent to which it will matter is limited. the selfish-mining attack also no longer works for a similar reason. if you fail to include uncles, then the guy after you will. there are four chances for an uncle to get in, so not including uncles is a 4-party prisoner's dilemma between anonymous players a game that is doomed to end badly for everyone involved (except of course the uncles themselves). there is also one last concern with this strategy: we saw that rewarding all uncles makes 51% attacks cost-free, so are they cost-free here? beyond one block, the answer is no; although the first block of an attempted fork will get in as an uncle and receive its 15/16x reward, the second and third and all subsequent ones will not, so starting from two confirmations attacks still cost miners almost as much as they did before. twelve seconds, really? the most surprising finding about decker and wattenhofer's finding is the sheer length of time that blocks take to propagate an amazingly slow 12 seconds. in decker and wattenhofer's analysis, the 12 second delay is actually mostly because of the need to download and verify the blocks themselves; ie. the algorithm that bitcoin clients follow is: def on_receive_block(b): if not verify_pow_and_header(b): return if not verify_transactions(b): return accept(b) start_broadcasting(b) however, decker and wattenhofer did propose a superior strategy which looks something like this: def on_receive_header(h): if not verify_pow_and_header(h): return ask_for_full_block(h, callback) start_broadcasting(h) def callback(b): start_broadcasting(b) if not verify_transactions(b): stop_broadcasting(b) return accept(b) this allows all of the steps to happen in parallel; headers can get broadcasted first, then blocks, and the verifications do not need to all be done in series. although decker and wattenhofer do not provide their own estimate, intuitively this seems like it may speed up propagation by 25-50%. the algorithm is still non-exploitable because in order to produce an invalid block that passes the first check a miner would still need to produce a valid proof of work, so there is nothing that the miner could gain. another point that the paper makes is that the transit time is, beyond a certain point, proportional to block size; hence, cutting block size by 50% will also cut transit time to something like 25-40%; the nonscaling portion of the transit time is something like 2s. hence, a 3-second target block time (and 5s actual block time) may be quite viable. as usual, we'll be more conservative at first and not take things that far, but a block time of 12s does nevertheless seem to be very much achievable. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements gav’s ethereum ðξv update iii | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search gav’s ethereum ðξv update iii posted by gavin wood on november 18, 2014 research & development i'm gavin wood, a co-founder of ethereum and, along with vitalik buterin and jeffrey wilcke, one of the three directors of the eth dev, the nfp organisation that is managing the development (under contract from ethereum suisse) of the ethereum blockchain. this is a small update to let you all know what has been going on recently. i sit here on an immaculate couch that has been zapped forward in time from the 1960s. it is in the room that will become the chillout & wind-down room of the heart of the (c++) ethereum development operation. surrounding me is alex leverington on a bond villain's easy chair, and aeron buchanan stuck behind a locker that looks as though it was an original prop from m*a*s*h. lighting equipment from a soviet blade runner, now forgotten except in berlin's coolest districts where renaissance chemistry and 60s luxury breath frankensteinesque life into it, provides an unyielding glow to the work in progress. there is still much to be done here (i feel a little like i'm on the set of challenge anneka) but it is undeniably taking shape. this is thanks mostly to our own anneka rice, sarah o'neill, who is working around the clock to get this place ready for ðξvcon-0, our first developer symposium. helping her, similarly around the clock, is the inimitable roland, a hardened international interior outfitter whose memoirs i can't wait to read. on a personal note, i must say these last few months have been some of the busiest of my life. i spent the last couple of weeks between switzerland and the uk, visiting stephan, ian and louis. despite the draws of the north of england, it's nice to be back in berlin; the combination of great burgers and cocktails, beautiful surroundings and nice people makes it difficult to leave. awesome c++ coders are welcome to take that as a hint: we're still hiring (-: technicals during the last couple of weeks we've made a number of important revisions to the protocol, mostly provisions for creating light-client ðapp nodes. there will be a directors' post in due course detailing these, but suffice it to say we are as committed as ever that the ethereum blockchain make possible the massively multi-user decentralised applications for all sizes of devices. the seventh in our proof-of-concept series is awaiting imminent release and the final in the series, poc-8 will be starting development shortly. fresh meat as time goes on, our team moves from strength to strength. i'm pleased to announce that dr. sven ehlert has joined us. he will be leading development operations; cleaning up the build process, making the build as robust as possible, assisting caktux in our ci systems and, most importantly, helping architect a stress-testing harness in which we'll be simulating a series of extreme situations, measuring and analysing. he's also a scrum aficionado and will be helping us streamline some of our development processes as our team grows. it is with great pleasure i can also announce that dr. jutta steiner will also be working closely with us in the capacity of managing our security audit. as well as being an enthusiastic ðapp-developer, she comes with an excellent track record of handling projects and a superb understanding of not only this cutting edge technology but also the human processes that must go on behind it. i must also shout out to dr. andreas lubbe; though a long-time member of the berlin ethereum community and having worked on ethereum-related code (a notable devotee of node.js), we have recently started working much more closely together on the secure ethereum contract documentation (secdoc) framework and the associated natural language specification format, natspec. i look forward to some great collaboration. aside from lefteris, who began his first official day with us today (working with christian on solidity, and more specifically on the secdoc and natspec portions of it), we have two new developers joining us: yann levreau and arkadiy paronyan. yann, a recent arrival in berlin from his native france will be joined by arkadiy who is travelling all the way from moscow to become part of the team. both have substantial experience in c++ and related technologies and will be helping us flesh out the developer tools and in particular pave the way to the ide vision. finally, i'm happy to report that christoph jentzsch, though originally joining us for only 2 months (while taking time out from his doctoral studies), will be joining the project full time in the new year and continuing his much appreciated work on our tests and the general c++ health and robustness. ðξvcon-0 as time rushes by, sarah, roland and their team rush even more to finish our hub. for they know that come monday the 24th, berlin will have some new arrivals. developers and collaborators from around the globe will descend on 37a waldemarstraße, berlin 10999 for a week of getting everybody on the same page. it is devcon-0: ethereum's first developer symposium. conceived by myself and jeff on a sleepy train from zug to zurich as a means of getting the amsterdam/go guys on the same page as the berlin/c++ guys it has evolved into a showcase, set of seminars and workshops of all of ðξv, our technologies, our personnel and some of our close collaborators. it is a chance for us each to build lasting professional relationships and bond in what will become a project that may if not define, certainly form a hallmark, on our professional lifes. our hub will play host to around 40 people, the vast majority of which are accomplished technical minds that jeff, myself or vitalik has at one point or another mentioned, and for the period of a week we will be chatting, mingling and sharing our ideas, hopes and dreams for everything blockchain, decentralised and disruption related. it's going to be awesome: look out for the videos! ever closer aside from the continuing work towards starting poc-8 and the alpha series, i'm glad to report that the solidity project storms onwards under the stewardship of christian: the first contracts compiled with solidity have been delivered and tested working on the testnet, and as i write this i see another pull request for state mappings. great stuff. alex has also been working tirelessly on our crypto code and is now beginning work on the p2p layer, the full strategy for which we'll be seeing in his address at ðξvcon. marek and marian have also been busy on the javascript api, and i can assure any javascript ðapp developers that they will have a lot to look forward to in poc-8. summing up there are also a few other developments and personnel i'd love to announce, but i fear, once again, it will have to wait until next time. watch this space for a post-ðξvcon update! gav. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements eip-2666: repricing of precompiles and keccak256 function ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-2666: repricing of precompiles and keccak256 function authors alex vlasov (@shamatar) created 2020-05-22 discussion link https://ethereum-magicians.org/t/eip2666-global-precompiles-repricing-and-many-more-discussion-thread/4332 requires eip-1352, eip-2046, eip-2565 table of contents simple summary abstract motivation specification rationale detailed summary of repricing approach benchmarks on the most popular clients tooling and data note on formulas structure backwards compatibility test cases implementation security considerations copyright simple summary this eip tries to set prices of certain precompiles and built-in evm function to be in line with their performance, consumed resources and newer changes in evm itself. new price formulas are proposed for: sha256 precompile (0x02) ripemd precompile (0x03) keccak256 opcode (0x20) abstract costs of many precompiles and built-in functions are invalid at the current state of the clients. this eip contains a list of changes to the pricing formulas to better reflect underlying computations’ structure. motivation historical pricing for these functions in evm does not reflect inner structure of the underlying computations (inner structure of the hash functions). eip-2046 changes a staticcall (0xfa) cost to precompile and it may be necessary to adjust costs of some precompiles that may have taken old large cost (700 gas) into account and tried to compensate for it some precompiles are overpriced and their pricing formulas do not reflect the structure of underlying functions keccak256 built-in function (opcode) in evm has pricing that does not reflect underlying hash function structure specification if block_number >= x set the gas cost of the following precompiles and keccak256 opcode: sha256 (precompile 0x02): 10 + ((len(input) + 8)/64 + 1) * 9 ripemd (precompile 0x03): 6 + ((len(input) + 8)/64 + 1) * 12 keccak256 (0x20): 13 + (len(input)/136 + 1)*15 this eip ideally requires that modexp repricing is implemented to also accurately reflect that there is no implicit compensation for an old staticcall (0xfa) cost (pre-2046). rationale cost of functions being executed must accurately reflect real cpu time spent on computations, so benchmarking was performed for current precompiles and keccak256 function to measure running time versus input parameters. detailed summary of repricing approach this eip relies on two facts: apriori knowledge of the inner strucute of the hash functions benchmarks provided by the client teams for some reasonable range of input lengths for random inputs (random byte strings of a given length) benchmarks on the most popular clients necessary benchmarks for eip-2666 were provided by the clients and raw form is assembled in here sha256 precompile currently it’s 60 gas + 12 gas per 32 byte word (number of words is ceil(len(input)/word_len) here and in similar places. if there is no floor or ceil specifier all divisions below are integer divisions (floor divisions)). proposed formula is a * ((len(input) + 8) / 64 + 1) + b, with coefficients below a b geth 5 3 oe 9 4 besu 5 10 nethermind 10 5 eip-2666 proposes a = 9, b = 10. there are no large one-off costs in this precompile, so it’s eip-2046 safe. ripemd precompile currently it’s 600 gas + 120 gas per 32 byte word. proposed formula is a * ((len(input) + 8) / 64 + 1) + b, with coefficients below a b geth 12 6 oe 8 2 besu 29 16 nethermind 10 6 eip-2666 proposes a = 12, b = 6. there are no large one-off costs in this precompile, so it’s eip-2046 safe. besu expects to have performance improvements by the end of the year. keccak256 performance currently it’s 30 gas + 6 gas per 32 byte word. proposed formula is a * (len(input) / 136 + 1) + b, with coefficients below a b geth 13 13 oe 15 2 besu 19 28 nethermind 16 3 eip-2666 proposes a = 15, b = 13. there are no large one-off costs in this precompile, so it’s eip-2046 safe. besu expects to have performance improvements by the end of the year. tooling and data reference material (from benchmarks of different clients) with raw data can be found here. there is a repository available with inputs for benchmarking and precompiles testing here that can be used by client teams to perform all the necessary measurements. raw besu benchmarks. note on formulas structure there are terms in formulas that look like a * 1 and those are explicitly not combined to the b coefficient to reflect that hash of an empty byte array requires to perform a round of hashing anyway. backwards compatibility precompile repricings has happened in a past and can be considered standard procedure. gas costs of many contracts is expected to reduce that may break re-entrancy protection measures based on fixed gas costs. in any case, such protection should have never been considered good and final. test cases let’s consider a simple example of keccak256 hash of 0, 64 and 160 bytes that can is a simple sanity check for implementation. hash 0 bytes: old price: 30 + 6 * ceil(0 / 32) = 30 gas new price: 15 * (0/136 + 1) + 13 = 28 gas hash 64 bytes old price: 30 + 6 * ceil(64 / 32) = 42 gas new price: 15 * (64/136 + 1) + 13 = 28 gas hash 160 bytes old price: 30 + 6 * ceil(160 / 32) = 60 gas new price: 15 * (160/136 + 1) + 13 = 43 gas implementation there is no reference implementation at the time of writing as it requires just a simple change of constants in major clients. security considerations as described in backward compatibility section in some cases reduction of cost may allow e.g. re-entrancy that was not expected before, but we think that re-entrancy protection based on fixed gas costs is anyway flawed design decision. copyright copyright and related rights waived via cc0. citation please cite this document as: alex vlasov (@shamatar), "eip-2666: repricing of precompiles and keccak256 function [draft]," ethereum improvement proposals, no. 2666, may 2020. [online serial]. available: https://eips.ethereum.org/eips/eip-2666. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-6988: elected block proposer has not been slashed ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: core eip-6988: elected block proposer has not been slashed prevents a slashed validator from being elected as a block proposer authors mikhail kalinin (@mkalinin) created 2023-05-04 discussion link https://ethereum-magicians.org/t/eip-6988-elected-block-proposer-has-not-been-slashed/14349 table of contents abstract motivation specification rationale modifying get_beacon_proposer_index backwards compatibility test cases reference implementation security considerations copyright abstract introduces a modification to the consensus layer specification which ensures that slashed validator cannot be elected as block proposer. motivation a block proposed by a slashed validator is rejected by the corresponding validity check in the phase0/process_block_header function as defined in the consensus layer specification. at the same time the definition of the phase0/compute_proposer_index allows for a slashed validator to be elected as a proposer. this contradiction effectively leads to a missed proposal if it is supposed to be made by a slashed validator. the impact of the proposed fix in the case of a single slashing on ethereum mainnet is negligible but it becomes significant in the case of correlated slashings. for instance, a correlated slashing of 1/10th of a validator set can lead to 1/10th of missed proposals in a number of epochs after the slashing. specification specification of the proposed change can be found in /_features/eip6988/beacon-chain.md. rationale modifying get_beacon_proposer_index this function is modified to read a proposer index from a beacon state if a slot of a latest block header is the same as the state.slot. this modification is done to make the function return correct proposer index in the case when the proposer of a given block is being slashed during processing of the block. backwards compatibility this fix changes proposer election mechanism in a backwards incompatible way and requires a hard fork to be deployed. test cases the following test cases were added to cover this change: test_slashed_proposer_rewarded_for_sync_aggregate_inclusion test_slashed_proposer_rewarded_for_attestation_inclusion test_slashed_validator_not_elected_for_proposal test_slashed_validator_elected_for_proposal reference implementation reference implementation is in the same place as specification. security considerations there are no observed security issues introduced by the proposed change. copyright copyright and related rights waived via cc0. citation please cite this document as: mikhail kalinin (@mkalinin), "eip-6988: elected block proposer has not been slashed [draft]," ethereum improvement proposals, no. 6988, may 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-6988. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2003: evmc modules for implementations of precompiled contracts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-2003: evmc modules for implementations of precompiled contracts authors paweł bylica (@chfast), alex beregszaszi (@axic) created 2019-05-09 discussion link https://github.com/ethereum/evmc/issues/259 requires eip-1352 table of contents abstract specification rationale test cases implementations references copyright abstract evmc specifies a generic api for ethereum execution engines. this eip specifies a way of providing implementations of ethereum precompiled contracts using the evmc vm api. specification for the complete evmc specification visit the evmc documentation first. this eip is based on and is compatible with evmc abi version 6. the evmc module with implementations of precompiled contracts should: advertise the evmc_capability_precompiles capability in the get_capabilities() method. implement the execute() method in the following way: validate the incoming execution request requirements: the message kind (evmc_message::kind) is a call (evmc_call). the call destination address (evmc_message::destination) is within the range of precompiled contracts defined by eip-1352. there is no code provided (the code argument is null and code_size argument is 0). if the requirements are not fulfilled, abort execution with the evmc_rejected status code. check if the call destination address (evmc_message::destination) targets existing precompiled contract. consider the evm revision (evmc_revision) requested by the rev parameter of execute(). if yes, execute as follows: inspect the input data (evmc_message::input_data, evmc_message::input_size) and calculate the gas cost of the execution. compute the amount of gas left after execution by subtracting the gas cost from the call gas limit (evmc_message::gas). if gas left is negative, abort execution with the evmc_out_of_gas status code. otherwise, execute the code of the precompiled contract, return the evmc_success status code, the output and gas left (evmc_result::output_data, evmc_result::output_size, evmc_result::gas_left). otherwise, emulate execution of empty code by returning the evmc_success status code and gas left equal the call gas limit (evmc_message::gas). precompiled contract implementations are allowed to return two more evmc error codes: evmc_failure if the failure was caused due to something other than out of gas (e.g. input validation error) evmc_revert if the precompile doesn’t want to forfeit all supplied gas (as of may 2019 no such precompile exists) the client is not required to provide the host interface ([evmc_context] argument of execute() is set to null). therefore, the precompiled contracts implementation must not access the evmc_context. rationale it is very unlikely that any precompile will need to access or modify a contract state. not requiring the client to implement the evmc host interface removes the big portion of work needed for full evmc integration. test cases evmc provides the evmc-vmtester tool for checking compatibility with the evmc specification. implementations example of precompiles vm implementation ewasm precompiles aleth code for precompiles parity code for precompiles eip-1962 implemented as an evmc precompile module references evmc – ethereum client-vm connector api evmc documentation evmc vm implementation guide eip 1352: specify restricted address range for precompiles/system contracts copyright copyright and related rights waived via cc0. citation please cite this document as: paweł bylica (@chfast), alex beregszaszi (@axic), "eip-2003: evmc modules for implementations of precompiled contracts [draft]," ethereum improvement proposals, no. 2003, may 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2003. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5553: representing ip and its royalty structure ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-5553: representing ip and its royalty structure a way of representing intellectual property and its respective royalty structure on chain authors roy osherove (@royosherove) created 2022-08-17 discussion link https://ethereum-magicians.org/t/eip-5553-representing-intellectual-property-on-chain-with-royalty-rights/10551 requires eip-20, eip-721 table of contents abstract motivation specification royaltyportiontokens() function metadatauri() function changemetadatauri() function ledger() function rationale returning an array of eip-20 tokens presents a more robust royalty portions structure/ separating the ip contract from the collectible and licensing nfts enables scaling licensing types a single pointer to the ip’s metadata reference implementation security considerations copyright abstract this proposal introduces a generic way to represent intellectual property on chain, along with a refined royalty representation mechanism and associated metadata link. this standard is not associated with a specific type of ip and could represent many types of ip, such as musical ip, videos, books, images, and more. the standard is kept very generic to allow the industry to evolve new ecosystems that can all rely on the same basic standard at their core. this standard allows market participants to: 1) observe the canonical on-chain representation of an intellectual property 2) discover its attached metadata 3) discover its related royalty structure 4) this will enable building registration, licensing, and payout mechanisms for intellectual property assets in the future. motivation there is no accepted standard mechanism to license intellectual property or to represent it, except using traditional nfts. however, regular nfts only represent a collectible item use case and cannot easily represent more complicated use cases of licensing ip for different types of uses. we can enable such licensing mechanisms if we can: 1) declare that ip exists, separately from its purchase ability 2) declare possibly multiple interested parties to be paid for such ip for 1, no standard exists today. for 2, traditional split standards exist based on nft purchases or through mechanisms like 0xsplits. while these solve the main problem, they do not contain the ability to name multiple types of collaboration participants. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. contracts that want to represent ip on chain must implement eip-721 and this proposal this standard extends eip-721 with the following iiprepresentation (ipr for short) interface. implementers of this standard must have all of the following functions: royaltyportiontokens() function this function must return an array of addresses related to eip-20 tokens that must represent royalty portions to different types of interested parties. these royalty portion tokens represent a more granular and streamlined way to declare royalty splits for multiple collaboration participants for the creation of the ip. for example, for a musical ip, we might have two tokens representing the composition/writing/publishing royalty portion side and the recording/master side. these royalty portion tokens are distributed to the collaboration participants and can later be queried by the various holders to distribute royalties. i.e., if one holds 10% of a royalty portion token, that holder will get 10% of the financial distribution related to that type of royalty. metadatauri() function this function must return the uri to a metadata file containing any required metadata for the ip or an empty string. each ip type may implement its metadata standard, defined separately. the file must be hosted in ipfs, arweave, or other decentralized content-addressable systems in which the file’s contents are not changeable without changing the uri. changemetadatauri() function this function allows changing the metadata uri to point to a new version of the metadata file. calling this function must trigger the event metadatachanged in case of success. ledger() function this function must return the registry or registrar contract address or an eoa account that initialized the ip and associated royalty tokens. an ip representation may be registered in multiple places by different actors for different purposes. this function enables market participants to discover which registry mechanism is the parent of the ip and might have special access rights to manage the ip. // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.9; import '@openzeppelin/contracts/interfaces/ierc165.sol'; /// /// @dev interface for intellectual property representation /// interface iiprepresentation is ierc165 { /// @notice called with the new uri to an updated metadata file /// @param _newuri the uri pointing to a metadata file (file standard is up to the implementer) /// @param _newfilehash the hash of the new metadata file for future reference and verification function changemetadatauri(string memory _newuri, string memory _newfilehash) external ; /// @return array of addresses of erc20 tokens representing royalty portion in the ip /// @dev i.e implementing erc5501 (iroyaltyinteresttoken interface) function royaltyportiontokens() external view returns (address[] memory) ; /// @return the address of the contract or eoa that initialized the ip registration /// @dev i.e., a registry or registrar, to be implemented in the future function ledger() external view returns (address) ; /// @return the uri of the current metadata file for the ii p function metadatauri() external view returns (string memory) ; /// @dev event to be triggered whenever metadata uri is changed /// @param byaddress the addresses that triggered this operation /// @param olduri the uri to the old metadata file before the change /// @param oldfilehash the hash of the old metadata file before the change /// @param newuri the uri to the new metadata file /// @param newfilehash the hash of the new metadata file event metadadatachanged(address byaddress, string olduri, string oldfilehash, string newuri, string newfilehash); } rationale returning an array of eip-20 tokens presents a more robust royalty portions structure/ current royalty implementations deal only with a single type of royalty payment: nft sales. they also only allow a single type of royalty i.e., music nfts cannot pay different people in different scenarios. in other words, currently, a royalty split works the same way no matter what type of purchase or license deal has happened for all parties involved. with this proposal, multiple types of royalty scenarios are allowed. a classic case is the music industry, in which we have writing/composition royalties and recording/master royalties. different licensing types will pay different percentages to different parties based on context. in the case of a song cover, a license payment formula can be created so that that a) original ip’s writers get paid for using the lyrics or composition of the song b) recording artists of the original song do not get paid since their recording is not used c) recording artists of the new ip will get paid d) there are no writing royalties for the creators of the cover. moreover, this eip has a single structure that connects to all types of royalty types and allows finding them more easily. lastly, moving eip-20 tokens around is much easier than managing an 0xsplits contract. separating the ip contract from the collectible and licensing nfts enables scaling licensing types by separating the canonical version of the ip from its various licensed uses (nft purchase, streaming, usage of art and more.), this eip introduces a path for an ecosystem of various license types and payment distributions to evolve. in other words, when people use this scheme, they will not start by creating a music nft or art nft; they start by creating the ip representation and then create types of licenses or collectibles for it, each as its own sellable nft. a single pointer to the ip’s metadata the ipr points to metadata housed in ipfs or arweave and allows changing it and keeping track of the changes in a simple and standard way. today the only metadata standard is nft metadata extension, but it is impossible to know to which standard the document adheres. with different ip types, different metadata standards for different ip types can be formulated and have a simple, easy place to discover attached metadata. reference implementation implementing a musical ip representation (mipr for short) based on iiprepresentation // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.9; import '@openzeppelin/contracts/token/erc721/erc721.sol'; import "./interfaces/iiprepresentation.sol"; import "./interfaces/structs.sol"; contract musicalip is erc721, iiprepresentation { address public songledger; address public comptoken; address public rectoken; string public metadatauri; string public filehash; uint256 public tokenid; bool public activated =false; function supportsinterface(bytes4 interfaceid) public view virtual override( erc721, ierc165) returns (bool) { return interfaceid == type(iiprepresentation).interfaceid || super.supportsinterface(interfaceid); } function getinterfaceid() public pure returns (bytes4){ return type(iiprepresentation).interfaceid; } constructor ( uint256 _tokenid, address _songledger, songmintingparams memory _params, address _compaddress, address _recaddress ) erc721(_params.shortname, _params.symbol){ songledger = _songledger; comptoken = _compaddress; rectoken = _recaddress; metadatauri = _params.metadatauri; filehash = _params.filehash; tokenid = _tokenid; _safemint(_songledger, _tokenid); emit minted(_params.shortname,_songledger,_compaddress,_recaddress,_msgsender(),tokenid,_params.metadatauri); } function changemetadatauri(string memory _newuri,string memory _newfilehash) public { string memory olduri = metadatauri; string memory oldhash = filehash; metadatauri = _newuri; filehash = _newfilehash; emit metadatachanged(olduri, oldhash,_newuri,_newfilehash); } function royaltyportiontokens() external view returns (address[] memory) { address[] memory items = new address[](2); items[0] = comptoken; items[1] = rectoken; return items; } function ledger() external view returns (address) { return songledger; } event metadatachanged( string olduri, string oldfilehash, string newuri, string newfilehash ); event minted( string abbvname, address ledger, address comptoken, address rectoken, address creator, uint256 tokenid, string metadatauri ); } deploying a new musical ip using a simple song registry contract // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.9; import "@openzeppelin/contracts/utils/counters.sol"; import "./musicalip.sol"; import "./compositionroyaltytoken.sol"; import "./recordingroyaltytoken.sol"; contract simplesongledger is ierc721receiver { using counters for counters.counter; counters.counter private mipids; function onerc721received(address, address, uint256, bytes calldata) external pure returns (bytes4) { return ierc721receiver.onerc721received.selector; } function mintsong(songmintingparams memory _params) public { compositionroyaltytoken comp = new compositionroyaltytoken(address(this),"songcomp","comp"); recordingroyaltytoken rec = new recordingroyaltytoken(address(this),"songrec","rec"); mipids.increment(); musicalip mip = new musicalip( mipids.current(), address(this), _params, address(comp), address(rec) ); } } security considerations there might be potential security challenges of attackers persuading holders of royalty portion tokens to send them those tokens and gaining royalty portion in various iprs. however, these are not specific to royalties and are a common issue with eip-20 tokens. in the case of the ip registration ownership, it will be recommended that registry contracts own the ip registration, which will be non-transferrable (account bound to the registry that created it). copyright copyright and related rights waived via cc0. citation please cite this document as: roy osherove (@royosherove), "erc-5553: representing ip and its royalty structure [draft]," ethereum improvement proposals, no. 5553, august 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5553. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-7508: dynamic on-chain token attributes repository ethereum improvement proposals allcorenetworkinginterfaceercmetainformational ⚠️ draft standards track: erc erc-7508: dynamic on-chain token attributes repository dynamic on-chain storage of token attributes in a public-good repository. authors steven pineda (@steven2308), jan turk (@thunderdeliverer) created 2023-08-15 discussion link https://ethereum-magicians.org/t/dynamic-on-chain-token-attributes-repository/15667 requires eip-165 table of contents abstract motivation cross-collection interactivity perpetual store of attributes token evolution dynamic state tracking specification message format for presigned attribute pre-determined address of the attributes repository rationale backwards compatibility test cases reference implementation security considerations copyright abstract the public on-chain non-fungible token attributes repository standard provides the ability for erc-721 and erc-1155 compatible tokens to store their attributes on-chain available to any external smart contract interacting with them. this proposal introduces the ability to assign attributes to nfts in a public non-gated repository smart contract that is accessible at the same address in all of the networks. the repository smart contract is designed to be a common-good repository, meaning that it can be used by any erc-721 or erc-1155 compatible token. motivation with nfts being a widespread form of tokens in the ethereum ecosystem and being used for a variety of use cases, it is time to standardize additional utility for them. having the ability to store token’s attributes on chain allows for greater utility of tokens as it fosters cross-collection interactivity and provides perpetual store of attributes. this erc introduces new utilities for erc-721 and erc-1155 based tokens in the following areas: cross-collection interactivity perpetual store of attributes token evolution dynamic state tracking cross-collection interactivity storing attributes on-chain in a predictable format allows for cross-collection interactivity. this means that the attributes of a token can be used by any external smart contract without the need for the token to be aware of the external smart contract. for example, a token can represent a game character with its set of attributes and can be used in an unrelated game with the same stats without the need for retrieving these attributes from an off-chain source. this ensures that the data the game is using is legitimate and not tampered with in order to gain an advantage. perpetual store of attributes standardized on-chain token attributes allow for their perpetual storage. with off-chain attributes storage, the attributes are only available as long as the off-chain storage is available. if the storage is taken down, the attributes are lost. with on-chain attributes storage, the attributes are available as long as the blockchain is available. this increases the value of the token as it ensures that the attributes are available for as long as the token exists. token evolution on-chain storage of token attributes allows for the token to evolve over time. owner’s actions can impact the attributes of the token. since the attributes are stored on chain, the smart contract has the ability to modify the attribute once certain thresholds are met. this allows for token to become more interactive and reflect owner’s dedication and effort. dynamic state tracking on-chain storage of token attributes allows for dynamic state tracking. the attributes can be used to track the state of the token and its owner. this allows for the token to be used in a variety of use cases. one such use case is supply chains; the token can represent a product and its attributes can be used to track the state of the product as it transitions from pending, shipped, delivered, etc. specification the key words “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may”, and “optional” in this document are to be interpreted as described in rfc 2119. /// @title erc-7508 public on-chain nft attributes repository /// @dev see https://eips.ethereum.org/eips/eip-7508 /// @dev note: the erc-165 identifier for this interface is 0x07cd44c7. pragma solidity ^0.8.21; interface irmrktokenattributesrepository /*is ierc165*/ { /** * @notice a list of supported access types. * @return the `issuer` type, where only the issuer can manage the parameter. * @return the `collaborator` type, where only the collaborators can manage the parameter. * @return the `issuerorcollaborator` type, where only the issuer or collaborators can manage the parameter. * @return the `tokenowner` type, where only the token owner can manage the parameters of their tokens. * @return the `specificaddress` type, where only specific addresses can manage the parameter. */ enum accesstype { issuer, collaborator, issuerorcollaborator, tokenowner, specificaddress } /** * @notice structure used to represent a string attribute. * @return key the key of the attribute * @return value the value of the attribute */ struct stringattribute { string key; string value; } /** * @notice structure used to represent an uint attribute. * @return key the key of the attribute * @return value the value of the attribute */ struct uintattribute { string key; uint256 value; } /** * @notice structure used to represent a boolean attribute. * @return key the key of the attribute * @return value the value of the attribute */ struct boolattribute { string key; bool value; } /** * @notice structure used to represent an address attribute. * @return key the key of the attribute * @return value the value of the attribute */ struct addressattribute { string key; address value; } /** * @notice structure used to represent a bytes attribute. * @return key the key of the attribute * @return value the value of the attribute */ struct bytesattribute { string key; bytes value; } /** * @notice used to notify listeners that a new collection has been registered to use the repository. * @param collection address of the collection * @param issuer address of the issuer of the collection; the addess authorized to manage the access control * @param registeringaddress address that registered the collection * @param useownable a boolean value indicating whether the collection uses the ownable extension to verify the * issuer (`true`) or not (`false`) */ event accesscontrolregistration( address indexed collection, address indexed issuer, address indexed registeringaddress, bool useownable ); /** * @notice used to notify listeners that the access control settings for a specific parameter have been updated. * @param collection address of the collection * @param key the name of the parameter for which the access control settings have been updated * @param accesstype the accesstype of the parameter for which the access control settings have been updated * @param specificaddress the specific addresses that has been updated */ event accesscontrolupdate( address indexed collection, string key, accesstype accesstype, address specificaddress ); /** * @notice used to notify listeners that a new collaborator has been added or removed. * @param collection address of the collection * @param collaborator address of the collaborator * @param iscollaborator a boolean value indicating whether the collaborator has been added (`true`) or removed * (`false`) */ event collaboratorupdate( address indexed collection, address indexed collaborator, bool iscollaborator ); /** * @notice used to notify listeners that a string attribute has been updated. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @param value the new value of the attribute */ event stringattributeupdated( address indexed collection, uint256 indexed tokenid, string key, string value ); /** * @notice used to notify listeners that an uint attribute has been updated. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @param value the new value of the attribute */ event uintattributeupdated( address indexed collection, uint256 indexed tokenid, string key, uint256 value ); /** * @notice used to notify listeners that a boolean attribute has been updated. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @param value the new value of the attribute */ event boolattributeupdated( address indexed collection, uint256 indexed tokenid, string key, bool value ); /** * @notice used to notify listeners that an address attribute has been updated. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @param value the new value of the attribute */ event addressattributeupdated( address indexed collection, uint256 indexed tokenid, string key, address value ); /** * @notice used to notify listeners that a bytes attribute has been updated. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @param value the new value of the attribute */ event bytesattributeupdated( address indexed collection, uint256 indexed tokenid, string key, bytes value ); /** * @notice used to register a collection to use the rmrk token attributes repository. * @dev if the collection does not implement the ownable interface, the `useownable` value must be set to `false`. * @dev emits an {accesscontrolregistration} event. * @param collection the address of the collection that will use the rmrk token attributes repository. * @param issuer the address of the issuer of the collection. * @param useownable the boolean value to indicate if the collection implements the ownable interface and whether it * should be used to validate that the caller is the issuer (`true`) or to use the manually set issuer address * (`false`). */ function registeraccesscontrol( address collection, address issuer, bool useownable ) external; /** * @notice used to manage the access control settings for a specific parameter. * @dev only the `issuer` of the collection can call this function. * @dev the possible `accesstype` values are: * [ * issuer, * collaborator, * issuerorcollaborator, * tokenowner, * specificaddress, * ] * @dev emits an {accesscontrolupdated} event. * @param collection the address of the collection being managed. * @param key the key of the attribute * @param accesstype the type of access control to be applied to the parameter. * @param specificaddress the address to be added as a specific addresses allowed to manage the given * parameter. */ function manageaccesscontrol( address collection, string memory key, accesstype accesstype, address specificaddress ) external; /** * @notice used to manage the collaborators of a collection. * @dev the `collaboratoraddresses` and `collaboratoraddressaccess` arrays must be of the same length. * @dev emits a {collaboratorupdate} event. * @param collection the address of the collection * @param collaboratoraddresses the array of collaborator addresses being managed * @param collaboratoraddressaccess the array of boolean values indicating if the collaborator address should * receive the permission (`true`) or not (`false`). */ function managecollaborators( address collection, address[] memory collaboratoraddresses, bool[] memory collaboratoraddressaccess ) external; /** * @notice used to set a number attribute. * @dev emits a {uintattributeupdated} event. * @param collection address of the collection receiving the attribute * @param tokenid the token id * @param key the attribute key * @param value the attribute value */ function setuintattribute( address collection, uint256 tokenid, string memory key, uint256 value ) external; /** * @notice used to set a string attribute. * @dev emits a {stringattributeupdated} event. * @param collection address of the collection receiving the attribute * @param tokenid the token id * @param key the attribute key * @param value the attribute value */ function setstringattribute( address collection, uint256 tokenid, string memory key, string memory value ) external; /** * @notice used to set a boolean attribute. * @dev emits a {boolattributeupdated} event. * @param collection address of the collection receiving the attribute * @param tokenid the token id * @param key the attribute key * @param value the attribute value */ function setboolattribute( address collection, uint256 tokenid, string memory key, bool value ) external; /** * @notice used to set an bytes attribute. * @dev emits a {bytesattributeupdated} event. * @param collection address of the collection receiving the attribute * @param tokenid the token id * @param key the attribute key * @param value the attribute value */ function setbytesattribute( address collection, uint256 tokenid, string memory key, bytes memory value ) external; /** * @notice used to set an address attribute. * @dev emits a {addressattributeupdated} event. * @param collection address of the collection receiving the attribute * @param tokenid the token id * @param key the attribute key * @param value the attribute value */ function setaddressattribute( address collection, uint256 tokenid, string memory key, address value ) external; /** * @notice sets multiple string attributes for a token at once. * @dev the `stringattribute` struct contains the following fields: * [ * string key, * string value * ] * @param collection address of the collection * @param tokenid id of the token * @param attributes an array of `stringattribute` structs to be assigned to the given token */ function setstringattributes( address collection, uint256 tokenid, stringattribute[] memory attributes ) external; /** * @notice sets multiple uint attributes for a token at once. * @dev the `uintattribute` struct contains the following fields: * [ * string key, * uint value * ] * @param collection address of the collection * @param tokenid id of the token * @param attributes an array of `uintattribute` structs to be assigned to the given token */ function setuintattributes( address collection, uint256 tokenid, uintattribute[] memory attributes ) external; /** * @notice sets multiple bool attributes for a token at once. * @dev the `boolattribute` struct contains the following fields: * [ * string key, * bool value * ] * @param collection address of the collection * @param tokenid id of the token * @param attributes an array of `boolattribute` structs to be assigned to the given token */ function setboolattributes( address collection, uint256 tokenid, boolattribute[] memory attributes ) external; /** * @notice sets multiple address attributes for a token at once. * @dev the `addressattribute` struct contains the following fields: * [ * string key, * address value * ] * @param collection address of the collection * @param tokenid id of the token * @param attributes an array of `addressattribute` structs to be assigned to the given token */ function setaddressattributes( address collection, uint256 tokenid, addressattribute[] memory attributes ) external; /** * @notice sets multiple bytes attributes for a token at once. * @dev the `bytesattribute` struct contains the following fields: * [ * string key, * bytes value * ] * @param collection address of the collection * @param tokenid id of the token * @param attributes an array of `bytesattribute` structs to be assigned to the given token */ function setbytesattributes( address collection, uint256 tokenid, bytesattribute[] memory attributes ) external; /** * @notice sets multiple attributes of multiple types for a token at the same time. * @dev emits a separate event for each attribute set. * @dev the `stringattribute`, `uintattribute`, `boolattribute`, `addressattribute` and `bytesattribute` structs consists * to the following fields (where `value` is of the appropriate type): * [ * key, * value, * ] * @param collection the address of the collection * @param tokenid the token id * @param stringattributes an array of `stringattribute` structs containing string attributes to set * @param uintattributes an array of `uintattribute` structs containing uint attributes to set * @param boolattributes an array of `boolattribute` structs containing bool attributes to set * @param addressattributes an array of `addressattribute` structs containing address attributes to set * @param bytesattributes an array of `bytesattribute` structs containing bytes attributes to set */ function settokenattributes( address collection, uint256 tokenid, stringattribute[] memory stringattributes, uintattribute[] memory uintattributes, boolattribute[] memory boolattributes, addressattribute[] memory addressattributes, bytesattribute[] memory bytesattributes ) external; /** * @notice used to set the uint attribute on behalf of an authorized account. * @dev emits a {uintattributeupdated} event. * @param setter address of the account that presigned the attribute change * @param collection address of the collection receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction * @param v `v` value of an ecdsa signature of the presigned message * @param r `r` value of an ecdsa signature of the presigned message * @param s `s` value of an ecdsa signature of the presigned message */ function presignedsetuintattribute( address setter, address collection, uint256 tokenid, string memory key, uint256 value, uint256 deadline, uint8 v, bytes32 r, bytes32 s ) external; /** * @notice used to set the string attribute on behalf of an authorized account. * @dev emits a {stringattributeupdated} event. * @param setter address of the account that presigned the attribute change * @param collection address of the collection receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction * @param v `v` value of an ecdsa signature of the presigned message * @param r `r` value of an ecdsa signature of the presigned message * @param s `s` value of an ecdsa signature of the presigned message */ function presignedsetstringattribute( address setter, address collection, uint256 tokenid, string memory key, string memory value, uint256 deadline, uint8 v, bytes32 r, bytes32 s ) external; /** * @notice used to set the bool attribute on behalf of an authorized account. * @dev emits a {boolattributeupdated} event. * @param setter address of the account that presigned the attribute change * @param collection address of the collection receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction * @param v `v` value of an ecdsa signature of the presigned message * @param r `r` value of an ecdsa signature of the presigned message * @param s `s` value of an ecdsa signature of the presigned message */ function presignedsetboolattribute( address setter, address collection, uint256 tokenid, string memory key, bool value, uint256 deadline, uint8 v, bytes32 r, bytes32 s ) external; /** * @notice used to set the bytes attribute on behalf of an authorized account. * @dev emits a {bytesattributeupdated} event. * @param setter address of the account that presigned the attribute change * @param collection address of the collection receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction * @param v `v` value of an ecdsa signature of the presigned message * @param r `r` value of an ecdsa signature of the presigned message * @param s `s` value of an ecdsa signature of the presigned message */ function presignedsetbytesattribute( address setter, address collection, uint256 tokenid, string memory key, bytes memory value, uint256 deadline, uint8 v, bytes32 r, bytes32 s ) external; /** * @notice used to set the address attribute on behalf of an authorized account. * @dev emits a {addressattributeupdated} event. * @param setter address of the account that presigned the attribute change * @param collection address of the collection receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction * @param v `v` value of an ecdsa signature of the presigned message * @param r `r` value of an ecdsa signature of the presigned message * @param s `s` value of an ecdsa signature of the presigned message */ function presignedsetaddressattribute( address setter, address collection, uint256 tokenid, string memory key, address value, uint256 deadline, uint8 v, bytes32 r, bytes32 s ) external; /** * @notice used to check if the specified address is listed as a collaborator of the given collection's parameter. * @param collaborator address to be checked. * @param collection address of the collection. * @return boolean value indicating if the address is a collaborator of the given collection's (`true`) or not * (`false`). */ function iscollaborator( address collaborator, address collection ) external view returns (bool); /** * @notice used to check if the specified address is listed as a specific address of the given collection's * parameter. * @param specificaddress address to be checked. * @param collection address of the collection. * @param key the key of the attribute * @return boolean value indicating if the address is a specific address of the given collection's parameter * (`true`) or not (`false`). */ function isspecificaddress( address specificaddress, address collection, string memory key ) external view returns (bool); /** * @notice used to retrieve the string type token attributes. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @return the value of the string attribute */ function getstringtokenattribute( address collection, uint256 tokenid, string memory key ) external view returns (string memory); /** * @notice used to retrieve the uint type token attributes. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @return the value of the uint attribute */ function getuinttokenattribute( address collection, uint256 tokenid, string memory key ) external view returns (uint256); /** * @notice used to retrieve the bool type token attributes. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @return the value of the bool attribute */ function getbooltokenattribute( address collection, uint256 tokenid, string memory key ) external view returns (bool); /** * @notice used to retrieve the address type token attributes. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @return the value of the address attribute */ function getaddresstokenattribute( address collection, uint256 tokenid, string memory key ) external view returns (address); /** * @notice used to retrieve the bytes type token attributes. * @param collection the collection address * @param tokenid the token id * @param key the key of the attribute * @return the value of the bytes attribute */ function getbytestokenattribute( address collection, uint256 tokenid, string memory key ) external view returns (bytes memory); /** * @notice used to retrieve the message to be signed for submitting a presigned uint attribute change. * @param collection the address of the collection smart contract of the token receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction after which the message is invalid * @return raw message to be signed by the authorized account */ function preparemessagetopresignuintattribute( address collection, uint256 tokenid, string memory key, uint256 value, uint256 deadline ) external view returns (bytes32); /** * @notice used to retrieve the message to be signed for submitting a presigned string attribute change. * @param collection the address of the collection smart contract of the token receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction after which the message is invalid * @return raw message to be signed by the authorized account */ function preparemessagetopresignstringattribute( address collection, uint256 tokenid, string memory key, string memory value, uint256 deadline ) external view returns (bytes32); /** * @notice used to retrieve the message to be signed for submitting a presigned bool attribute change. * @param collection the address of the collection smart contract of the token receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction after which the message is invalid * @return raw message to be signed by the authorized account */ function preparemessagetopresignboolattribute( address collection, uint256 tokenid, string memory key, bool value, uint256 deadline ) external view returns (bytes32); /** * @notice used to retrieve the message to be signed for submitting a presigned bytes attribute change. * @param collection the address of the collection smart contract of the token receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction after which the message is invalid * @return raw message to be signed by the authorized account */ function preparemessagetopresignbytesattribute( address collection, uint256 tokenid, string memory key, bytes memory value, uint256 deadline ) external view returns (bytes32); /** * @notice used to retrieve the message to be signed for submitting a presigned address attribute change. * @param collection the address of the collection smart contract of the token receiving the attribute * @param tokenid the id of the token receiving the attribute * @param key the attribute key * @param value the attribute value * @param deadline the deadline timestamp for the presigned transaction after which the message is invalid * @return raw message to be signed by the authorized account */ function preparemessagetopresignaddressattribute( address collection, uint256 tokenid, string memory key, address value, uint256 deadline ) external view returns (bytes32); /** * @notice used to retrieve multiple token attributes of any type at once. * @dev the `stringattribute`, `uintattribute`, `boolattribute`, `addressattribute` and `bytesattribute` structs consists * to the following fields (where `value` is of the appropriate type): * [ * key, * value, * ] * @param collection the collection address * @param tokenid the token id * @param stringkeys an array of string type attribute keys to retrieve * @param uintkeys an array of uint type attribute keys to retrieve * @param boolkeys an array of bool type attribute keys to retrieve * @param addresskeys an array of address type attribute keys to retrieve * @param byteskeys an array of bytes type attribute keys to retrieve * @return stringattributes an array of `stringattribute` structs containing the string type attributes * @return uintattributes an array of `uintattribute` structs containing the uint type attributes * @return boolattributes an array of `boolattribute` structs containing the bool type attributes * @return addressattributes an array of `addressattribute` structs containing the address type attributes * @return bytesattributes an array of `bytesattribute` structs containing the bytes type attributes */ function gettokenattributes( address collection, uint256 tokenid, string[] memory stringkeys, string[] memory uintkeys, string[] memory boolkeys, string[] memory addresskeys, string[] memory byteskeys ) external view returns ( stringattribute[] memory stringattributes, uintattribute[] memory uintattributes, boolattribute[] memory boolattributes, addressattribute[] memory addressattributes, bytesattribute[] memory bytesattributes ); /** * @notice used to get multiple sting parameter values for a token. * @dev the `stringattribute` struct contains the following fields: * [ * string key, * string value * ] * @param collection address of the collection the token belongs to * @param tokenid id of the token for which the attributes are being retrieved * @param stringkeys an array of string keys to retrieve * @return an array of `stringattribute` structs */ function getstringtokenattributes( address collection, uint256 tokenid, string[] memory stringkeys ) external view returns (stringattribute[] memory); /** * @notice used to get multiple uint parameter values for a token. * @dev the `uintattribute` struct contains the following fields: * [ * string key, * uint value * ] * @param collection address of the collection the token belongs to * @param tokenid id of the token for which the attributes are being retrieved * @param uintkeys an array of uint keys to retrieve * @return an array of `uintattribute` structs */ function getuinttokenattributes( address collection, uint256 tokenid, string[] memory uintkeys ) external view returns (uintattribute[] memory); /** * @notice used to get multiple bool parameter values for a token. * @dev the `boolattribute` struct contains the following fields: * [ * string key, * bool value * ] * @param collection address of the collection the token belongs to * @param tokenid id of the token for which the attributes are being retrieved * @param boolkeys an array of bool keys to retrieve * @return an array of `boolattribute` structs */ function getbooltokenattributes( address collection, uint256 tokenid, string[] memory boolkeys ) external view returns (boolattribute[] memory); /** * @notice used to get multiple address parameter values for a token. * @dev the `addressattribute` struct contains the following fields: * [ * string key, * address value * ] * @param collection address of the collection the token belongs to * @param tokenid id of the token for which the attributes are being retrieved * @param addresskeys an array of address keys to retrieve * @return an array of `addressattribute` structs */ function getaddresstokenattributes( address collection, uint256 tokenid, string[] memory addresskeys ) external view returns (addressattribute[] memory); /** * @notice used to get multiple bytes parameter values for a token. * @dev the `bytesattribute` struct contains the following fields: * [ * string key, * bytes value * ] * @param collection address of the collection the token belongs to * @param tokenid id of the token for which the attributes are being retrieved * @param byteskeys an array of bytes keys to retrieve * @return an array of `bytesattribute` structs */ function getbytestokenattributes( address collection, uint256 tokenid, string[] memory byteskeys ) external view returns (bytesattribute[] memory); } message format for presigned attribute the message to be signed by the setter in order for the attribute setting to be submitted by someone else is formatted as follows: keccak256( abi.encode( domain_separator, method_typehash, collection, tokenid, key, value, deadline ) ); the values passed when generating the message to be signed are: domain_separator the domain separator of the attribute repository smart contract method_typehash the typehash of the method being called. the supported values, depending on the method are: set_uint_attribute_typehash used for setting uint attributes set_string_attribute_typehash used for setting string attributes set_bool_attribute_typehash used for setting bool attributes set_bytes_attribute_typehash used for setting bytes attributes set_address_attribute_typehash used for setting address attributes collection address of the collection containing the token receiving the attribute tokenid id of the token receiving the attribute key the attribute key value the attribute value of the appropriate type deadline unix timestamp of the deadline for the signature to be submitted. the signed message submitted after the deadline must be rejected the domain_separator is generated as follows: keccak256( abi.encode( "erc-7508: public non-fungible token attributes repository", "1", block.chainid, address(this) ) ); the set_uint_attribute_typehash is generated as follows: keccak256( "setuintattribute(address collection,uint256 tokenid,string memory key,uint256 value)" ); the set_string_attribute_typehash is generated as follows: keccak256( "setstringattribute(address collection,uint256 tokenid,string memory key,string memory value)" ); the set_bool_attribute_typehash is generated as follows: keccak256( "setboolattribute(address collection,uint256 tokenid,string memory key,bool value)" ); the set_bytes_attribute_typehash is generated as follows: keccak256( "setbytesattribute(address collection,uint256 tokenid,string memory key,bytes memory value)" ); the set_address_attribute_typehash is generated as follows: keccak256( "setaddressattribute(address collection,uint256 tokenid,string memory key,address value)" ); each chain, that the attributes repository smart contract is deployed in, will have a different domain_separator value due to chain ids being different. pre-determined address of the attributes repository the address of the emotable repository smart contract is designed to resemble the function it serves. it starts with 0xa77b75 which is the abstract representation of attbts. the address is: 0xa77b75d5fdec6e6e8e00e05c707a7ca81a3f9f4a rationale designing the proposal, we considered the following questions: should we refer to the values stored by the repository as propertiers or attributes? historically values defining characteristics of tokens have been called properties, but have evolved in to being called attributes. referring to the dictionary, the property is defined as a quality or characteristic that something has, and the attribute is defined as a quality or feature of somebody/something. we felt that using the term attribute fits better and decided to use it. should the proposal specify access control? designing the proposal, we had two options: either to include the access control within the specification of the proposal or to leave the access control up to the implementers that desire to use the attributes repository. while considering this we also had to consider the usability and compatibility aspects of the repository. on one hand, including access control narrows down the freedom of implementation and requires the implementers to configure it before being able to use the repository. on the other hand, leaving access control up to implementers requires dedicated design of attributes access control within their smart contracts, increasing their size, complexity and deployment costs. another important thing to note is that including access control in the proposal makes it compatible with collections existing prior to the deployment of the repository and thus powers backwards-compatibility. should the proposal establish an attributes extension or a common-good repository? initially we set out to create an attributes extension to be used with any erc-721 compliant tokens. however, we realized that the proposal would be more useful if it was a common-good repository of token attributes. this way, the tokens that can utilize it are not only the new ones but also the old ones that have been around since before the proposal. an additional benefit of this course-correction is the compatibility with erc-1155 tokens. should we include only single-action operations, only multi-action operations, or both? we’ve considered including only single-action operations, where the user is only able to assign a single attribute to a single token, but we decided to include both single-action and multi-action operations. this way, the users can choose whether they want to assign an attribute to a single token or on multiple tokens at once. this decision was made for the long-term viability of the proposal. based on the gas cost of the network and the number of tokens in the collection, the user can choose the most cost-effective way of attribute assigning. should we add the ability to assign attributes on someone else’s behalf? while we did not intend to add this as part of the proposal when drafting it, we realized that it would be a useful feature for it. this way, the users can assign attributes on behalf of someone else, for example, if they are not able to do it themselves or if the attribute is earned through an off-chain activity. how do we ensure that attribute assignment on someone else’s behalf is legitimate? we could add delegates to the proposal; when a user delegates their right to assign attributes to someone else, but having the ability to do so opens up the possibility for abuse and improper setting of attributes. using ecdsa signatures, we can ensure that the user has given their consent to assign attribute on their behalf. this way, the user can sign a message with the parameters of the attribute and the signature can be submitted by someone else. should we add chain id as a parameter when assigning attribute to a token? we decided against this as we feel that additional parameter would rarely be used and would add additional cost to the attribute assignment transactions. if the collection smart contract wants to utilize on-chain token attributes, it requires the reactions to be recorded on the same chain. marketplaces and wallets integrating this proposal will rely on attributes to reside in the same chain as well, because if chain id parameter was supported this would mean that they would need to query the repository smart contract on all of the chains the repository is deployed in order to get the attributes of a given token. additionally, if the collection creator wants users to record their reactions on a different chain, they can still direct the users to do just that. the repository does not validate the existence of the token being reacted to (except in an instace where the attribute can be modified by the token’s owner), which in theory means that you can assign an attribute to non-existent token or to a token that does not exist yet. how should we reduce the cost of string usage in the repository? one fo the main issues we were dealing with while designing the proposal is the cost of string usage. we considered using bytes instead of strings, but decided against it as it would require the users to encode and decode the strings themselves. the solution for reducing the cost was to use a string indices. this means that the cost of setting a new string attribute or key will only be paid by the first user to do so. the subsequent users will only pay the cost of setting the index of the string attribute or key. we also extended this gas-saving approach to be applicable across the entire repository. this means that if the string was already set by one collection, any other collection using the same string will not have to pay the cost of setting the string again. backwards compatibility the attributes repository standard is fully compatible with erc-721 and erc-1155 and with the robust tooling available for implementations of erc-721 as well as with the existing erc-721 infrastructure. test cases tests are included in attributesrepository.ts. to run them in terminal, you can use the following commands: cd ../assets/eip-7508 npm install npx hardhat test reference implementation see attributesrepository.sol. security considerations the proposal does not envision handling any form of assets from the user, so the assets should not be at risk when interacting with an attributes repository. the ability to use ecdsa signatures to set attributes on someone else’s behalf introduces the risk of a replay attack, which the format of the message to be signed guards against. the domain_separator used in the message to be signed is unique to the repository smart contract of the chain it is deployed on. this means that the signature is invalid on any other chain and the attributes repositories deployed on them should revert the operation if a replay attack is attempted. another thing to consider is the ability of presigned message reuse. since the message includes the signature validity deadline, the message can be reused any number of times before the deadline is reached. the proposal only allows for a single value for a given key to be set, so the presigned message can not be abused to further modify the attribute value. however, if the service using the repository relies on the ability to revert or modify the attribute after certain actions, a valid presigned message can be used to re-assign the attribute of the token. we suggest that the services using the repository in cnjunction with presigned messages use deadlines that invalidate presigned messages after a reasonalby short period of time. caution is advised when dealing with non-audited contracts. copyright copyright and related rights waived via cc0. citation please cite this document as: steven pineda (@steven2308), jan turk (@thunderdeliverer), "erc-7508: dynamic on-chain token attributes repository [draft]," ethereum improvement proposals, no. 7508, august 2023. [online serial]. available: https://eips.ethereum.org/eips/eip-7508. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. the problem of censorship | ethereum foundation blog ef blog search skip to contentcategories r&d research & development events events org organizational esp ecosystem support program eth.org ethereum.org sec security nxbn next billion protocol protocol announcements languages search the problem of censorship posted by vitalik buterin on june 6, 2015 research & development one of the interesting problems in designing effective blockchain technologies is, how can we ensure that the systems remain censorship-proof? although lots of work has been done in cryptoeconomics in order to ensure that blockchains continue pumping out new blocks, and particularly to prevent blocks from being reverted, substantially less attention has been put on the problem of ensuring that transactions that people want to put into the blockchain will actually get in, even if "the powers that be", at least on that particular blockchain, would prefer otherwise. censorship-resistance in decentralized cryptoeconomic systems is not just a matter of making sure wikileaks donations or silk road 5.0 cannot be shut down; it is in fact a necessary property in order to secure the effective operation of a number of different financial protocols. to take a completely uncontroversial, but high-value, example, consider contracts for difference. suppose that parties a and b both place 100 eth into a contract betting on the gold/usd price, with the condition that if the price after 30 days is $1200, both get 100 eth back, but for every $1 that the price increases a gets 1 eth more and b gets 1 eth less. at the extremes, at $1000 b gets the entire 200 eth, and at $1200 a gets the entire 200 eth. in order for this contract to be a useful hedging tool, one more feature is required: if the price hits $1190 or $1010 at any point during those 30 days, the contract should process immediately, allowing both parties to take out their money and enter another contract to maintain the same exposure (the $10 difference is a safety margin, to give the parties the ability to withdraw and enter a new contract without taking a loss). now, suppose that the price hits $1195, and b has the ability to censor the network. then, b can prevent a from triggering the force-liquidation clause. such a drastic price change likely signals more volatility to come, so perhaps we can expect that when the contract ends there is a 50% chance the price will go back to $1145 and a 50% chance that it will hit $1245. if the price goes back to $1145, then once the contract ends b loses 45 eth. however, if the price hits $1245, then b loses only 100 eth from the price moving $145; hence, b's expected loss is only 72.5 eth and not the 95 eth that it would be if a had been able to trigger the force-liquidation clause. hence, by preventing a from publishing a transaction to the blockchain at that critical time, b has essentially managed to, in common economic and political parlance, privatize the profits and socialize the losses. other examples include auditable computation, where the ability to publish evidence of malfeasance within a particular time-frame is crucial to the mechanism's economic security, decentralized exchanges, where censorship allows users to force others to keep their exchange orders open longer than they intended, and schellingcoin-like protocols, where censors may force a particular answer by censoring all votes that give any other answer. finally, in systems like tendermint, consensus participants can use censorships to prevent other validators from joining the consensus pool, thereby cementing the power of their collusion. hence, all things taken together, anti-censorship is not even about civil liberties; it is about making it harder for consensus participants to engage in large-scale market manipulation conspiracies a cause which seems high on the regulatory agenda. what is the threat model? the first question to ask is, what is the economic model under which we are operating? who are the censors, how much can they do, and how much does it cost them? we will split this up into two cases. in the first case, the censors are not powerful enough to independently block transactions; in the tendermint case, this entails the censors having less than 33% of all validator positions, in which case they can certainly restrict transactions from their own blocks, but those transactions would simply make it into the next block that does not censor them, and that block would still get its requisite 67% signatures from the other nodes. in the second case, the censors are powerful enough; in the bitcoin case, we can think of the top five mining firms and data centers colluding, and in the tendermint case a group of very large stakeholders. this may seem like a silly scenario to worry about after all, many have argued that cryptoeconomic systems rely on a security assumption that such a large group of consensus participants cannot collude, and if they can then we have already lost. however, in those cases, we actually have a secondary defense: such a collusion would destroy the underlying ecosystem and currency, and thus be highly unprofitable to the parties involved. this argument is not perfect; we know that with bribe attacks it's possible for an attacker to set up a collusion where non-participation is a public good, and so all parties will participate even if it is collectively irrational for them, but it nevertheless does set up a powerful defense against one of the more important collusion vectors. with history reversion (ie. 51% attacks), it's clear why carrying out such an attack would destroy the ecosystem: it undermines literally the only guarantee that makes blockchains a single bit more useful than bittorrent. with censorship, however, it is not nearly clear that the same situation applies. one can conceivably imagine a scenario where a large group of stakeholders collude to first undermine specific highly undesirable types of transactions (eg. child porn, to use a popular boogeyman of censors and civil liberties activists complaining about censors alike), and then expand the apparatus over time until eventually it gets into the hands of some enterprising young hotshots that promptly decide they can make a few billion dollars through the cryptoeconomic equivalent of libor manipulation. in the later stages, the censorship may even be done in such a careful and selective way that it can be plausibly denied or even undetected. knowing the results of byzantine fault tolerance theory, there is no way that we can prevent a collusion with more than 33% participation in the consensus process from doing any of these actions absolutely. however, what we can try to do is one of two things: make censorship costly. make it impossible to censor specific things without censoring absolutely everything, or at least without shutting down a very large portion of the features of the protocol entirely. now, let us look at some specific ways in which we can do each one. cost the first, and simplest, way to discourage censorship is a simple one: making it unprofitable, or at least expensive. notably, proof of work actually fails this property: censorship is profitable, since if you censor a block you can (i) take all of its transactions for yourself, and (ii) in the long run take its block reward, as the difficulty adjustment process will reduce difficulty to ensure the block time remains at 10 minutes (or 15 seconds, or whatever) despite the loss of the miner that has been censored away. proof of stake protocols are also vulnerable to (i) by default, but because we can keep track of the total number of validators that are supposed to be participating there are specific strategies that we can take in order to make it less profitable. the simplest is to simply penalize everyone for anyone's non-participation. if 100 out of 100 validators sign a block, everyone gets 100% of the reward. but if only 99 validators sign, then everyone gets 99% of the reward. additionally, if a block is skipped, everyone can be slightly penalized for that as well. this has two sets of consequences. first, censoring blocks produced by other parties will cost the censors. second, the protocol can be designed in such a way that if censorship happens, altruists (ie. default software clients) can refuse to sign the censoring blocks, and thus inflict on the censors an additional expense. of course, some degree of altruism is required for this kind of cost strategy to have any effect if no one was altruistic, then everyone would simply anticipate being censored and not include any undesirable transactions in the first place, but given that assumption it does add substantial costs. timelock consensus as for the second approach, there are two primary strategies that can be undertaken. the first is to use timelock puzzles, a kind of encryption where a piece of data takes a particular amount of time in order to decrypt and which cannot be sped up via parallelization. the typical approach to timelock puzzles is using modular exponentiation; the basic underlying idea is to take a transaction d and generate an encrypted value c with the property: if you know p and q, then computing c from d and d from c are both easy; use the chinese remainder theorem to decompose the problem into: and then use fermat's little theorem to further decompose into: which can be done in a paltry log(n) steps using two rounds of the square-and-multiply algorithm, one for the inner modular exponent and one for the outer modular exponent. one can use the extended euclidean algorithm to compute modular inverses in order to run this calculation backwards. lacking p and q, however, someone would need to literally multiply c by itself n times in order to get the result and, very importantly, the process cannot be parallelized, so it would take just as long for someone with one computer as it would for someone with a thousand. hence, a transaction-sending protocol can be constructed as follows: sender creates transaction t sender encrypts t using p and q to get c, and sends c and pq to a validator alongside a zero-knowledge proof that the values were produced correctly. the validator includes c and pq into the blockchain there is a protocol rule that the validator must submit the correct original transaction t into the blockchain within 24 hours, or else risk losing a large security deposit. honest validators would be willing to participate because they know that they will be able to decrypt the value in time, but they have no idea what they are including into the blockchain until it is too late. under normal circumstances, the sender will also submit t into the blockchain themselves as soon as c is included simply to speed up transaction processing, but if the validators are malicious they will be required to submit it themselves within 24 hours in any case. one can even make the process more extreme: a block is not valid if there remain c values from more than 24 hours ago that have not yet been included. this approach has the advantage that gradual introduction of censorship is impossible outright; it's either all or nothing. however, the "all" is still not that much. the simplest way to get around the mechanism is for validators to simply collude and start requiring senders to send t, p and q alongside c, together with a zero-knowledge proof that all the values are correct. it would be a highly obvious and blatant move, but all in all not a very expensive one. an additional problem of the scheme is that it's highly unnatural, requiring substantial expense of computing power (not nearly as much as proof of work, but nevertheless an hour's worth of computing time on a single core) and slightly non-standard cryptography in order to accomplish. hence, one question is, is there some way in which we can do better? for a simple transaction processing system, the answer is likely no, barring improved versions of timelock that rely on network latency rather than computing power, perhaps in the spirit of andrew miller's nonoutsourceable puzzles. for a turing-complete object model, however, we do have some rather interesting alternatives. a key tool in our arsenal is the halting problem: given a computer program, the only absolutely reliable way to determine what it will do after a number of steps of execution is to actually run it for that long (note: the original formulation asks only whether the program will halt, but the inherent impossibility can be generalized to very many types of output and intermediate behavior). in the context of ethereum, this opens up a particular denial-of-service attack vector: if a censor wishes to block transactions that have an undesirable effect (eg. sending messages to or from a particular address), then that effect could appear after running for millions of computational steps, and so the censor would need to process every transaction and discard the ones that they want censored. normally, this is not a problem for ethereum: as long as a transaction's signature is correct, the transaction is well-formatted and there is enough ether to pay for it, the transaction is guaranteed to be valid and includable into the blockchain, and the including miner is guaranteed to get a reward proprtional to the amount of computation that the transaction is allowed to take up. here, however, the censor is introducing an additional artificial validity condition, and one that cannot be verified nearly so "safely". however, we cannot immediately assume that this denial-of-service vulnerability will be fatal: it only takes perhaps a tenth of a second to verify a maximally sized transaction, and one certainly can overcome attacks of that size. hence, we need to go a step further, and introduce an upcoming ethereum 1.1 feature: events. events are a feature that allows a contract to create a kind of delayed message that is only played at some prespecified block in the future. once an event is made, any block at the height at which the event is supposed to mature must play the event in order to be valid. hence, transaction senders can be clever, and create a hundred transactions that create a hundred events, only all of which together create an event that accomplishes some particular action that is not desired by censors. even now, censors trying to produce their blocks can still try to simulate a series of empty blocks following the block they are producing, to see if the sequence of events that they are generating will lead to any undesirable consequence. however, transaction senders can make life much harder for censors still: they can create sets of transactions that create events that don't by themselves do anything, but do lead to the sender's desired consequence in combination with some other transaction that happens regularly (eg. bloomberg publishing some data feed into their blockchain contract). relying on block timestamps or other unpredictable block data is another possibility. note that this also makes it much harder to enact another defense against these anti-censorship strategies: requiring transaction senders themselves to produce a zero-knowledge proof that their transactions bear no undesirable intent. to expand the functionality of this scheme, we can also add another protocol feature: create a specialized address where messages sent to that address are played as transactions. the messages would contain the transaction data in some form (eg. each message specifies one byte), after a few hundred blocks trigger events to combine the data together, and the data would then have to be immediately played as a regular transaction; once the initial transactions are in, there is no way around it. this would basically ensure that everything that can be done by sending transactions (the primary input of the system) can be done through this kind of covert latent message scheme. hence, we can see how blocking such circumventions will very likely be pretty much impossible to do completely and absolutely; rather, it will be likely a constant two-sided war of heuristics versus heuristics where neither side would have a permanent upper hand. we may see the development of centralized firms whose sole purpose is to accept any transaction and find some way to "sneak it in" to the blockchain in exchange for a fee, and these firms would consistently update their algorithms in response to the updated algorithms of the parties that are trying to work against their previous algorithms to block the attempt. perhaps, this is the best that we can do. anti-censorship and finality it is important to note that the above by itself does not prove that censorship is extremely expensive all on its own. rather, it shows that, if developers take care to add certain features into the blockchain protocol, censorship can be made as hard as reversion. this still leaves the question of how difficult reversion is in the first place. a lot of earlier consensus protocols, including proof of work and naive versions of proof of stake, do not make small-depth reversion very difficult; hence, if it takes a hundred blocks to realize that an undesirable transaction has successfully entered the system, then it would be a major inconvenience but the validators would be able to discard the old blockchain and create a new one, with all of the transactions from the old chain included in order in order to avoid inconveniencing anyone else (although anyone that was using the blockchain as a source of randomness would unfortunately be out of their luck). newer protocols like tendermint, however, use security deposits to make reverting even one block almost impossible, and so do not run into this problem; if you can get the delayed events into the blockchain at all, you've already won. this, incidentally, is an important case study of the importance of "bribe attacks" as a theoretical concern in cryptoeconomics: even though literal bribes may in many cases be unrealistic, external incentive adjustments can come from any source. if one can prove that blockchains are extremely expensive to revert, then one can be assured that they will be extremely expensive to revert for any purpose, including attacker bribes and external desires to revert transactions for some particular purpose. previous post next post subscribe to protocol announcements sign up to receive email notifications for protocol-related announcements, such as network upgrades, faqs or security issues. you can opt-out of these at any time. sign up ethereum foundation • ethereum.org • esp • bug bounty program • do-not-track • archive categories research & development • events • organizational • ecosystem support program • ethereum.org • security • next billion • protocol announcements erc-1386: attestation management contract ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: erc erc-1386: attestation management contract authors weiwu zhang , james sangalli created 2018-09-08 discussion link https://github.com/ethereum/eips/issues/1386 table of contents introduction purpose example use cases draft interface related erc’s introduction very often, we will need to use attestations like “alice lives in australia” on the blockchain; that is issued by a valid issuer off chain for privacy reasons and is revokable inside a smart contract. an issuer can create a smart contract where he revokes multiple attestations in one go by building a bloom filter of all the hashes of the revoked attestations. an issuer can also put the validation method in their smart contract that can be called by other smart contracts who need to validate attestations issued by them. this allows each attestor to update their attestation format separately. purpose this erc provides an interface for attestation issuers to manage their attestation signing keys and the attestations that are issued off chain for actions such as revocation and validation. in our draft implementation we include functions to hold cryptographic attestations, change the issuing contracts of attestations, revoke attestations and verify the authenticity of a cryptographic attestation. example use cases let’s say that our friend, alice, wants to buy a bottle of wine to consume with her friends. she wants to do the order online and have it delivered to her home address whilst paying for it with ether. alice has a cryptographic attestation from her local road and maritime services who attests to her age, date of birth, country of residence and ability to drive. alice is able to split up this attestation (see merkle tree attestations erc here) and provides only the leaf that states she is over the age of 21. alice goes to buy the wine through the wine vendors smart contract and feeds in the merkle tree attestation proving that she is above 21 and can thus buy the wine, whilst attaching the appropriate amount of ether to complete the purchase. the issuer smart contract is able to validate her attestation, check that the issuer contract is valid and capable of performing such an attestation to her age. in this case it would have to be from someone like a driver’s licence authority, as attestations to age from a school id are not of a high enough capacity. the wine vendors smart contract validates the attestation, checks the payment amount is correct and credits alice with the wine tokens she needs to complete the sale and deliver the wine. when the wine vendor shows up to her apartment with the wine, there is no need to prove her age again. draft interface /* each attestation issuer should provide their own verify() for the * attestations they issued. there are two reasons for this. first, we * need to leave room for new attestation methods other than the * merkle tree format we are recommending. second, the validity of the * attestation may depend on the context that only the attestor * knows. for example, a ticket as an attestation issued on a * successful redemption of an american express credit */ contract issuer { struct attestation { bytes32[] merklepath; bool valid; uint8 v; bytes32 r; bytes32 s; address attestor; address recipient; bytes32 salt; bytes32 key; bytes32 val; }` /* verify the authenticity of an attestation */ function verify(attestation attestation); function addattestorkey(address newattestor, string capacity, uint expiry); /* this should call the revoke first */ function replacekey(address attestortoreplace, string capacity, uint expiry, address newattestor); /* this revokes a single key */ function removekey(address attestor); /* if the key exists with such capacity and isn't revoked or expired */ function validatekey(address attestor, string capacity) returns (bool); /* revoke an attestation by replace the bloom filter, this helps preserve privacy */ function revokeattestations(bloomfilter b); } please click here to see a draft implementation of this interface related erc’s #1388 #1387 citation please cite this document as: weiwu zhang , james sangalli , "erc-1386: attestation management contract [draft]," ethereum improvement proposals, no. 1386, september 2018. [online serial]. available: https://eips.ethereum.org/eips/eip-1386. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-658: embedding transaction status code in receipts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: core eip-658: embedding transaction status code in receipts authors nick johnson created 2017-06-30 requires eip-140 table of contents abstract motivation specification rationale copyright abstract this eip replaces the intermediate state root field of the receipt with a status code indicating if the top-level call succeeded or failed. motivation with the introduction of the revert opcode in eip140, it is no longer possible for users to assume that a transaction failed iff it consumed all gas. as a result, there is no clear mechanism for callers to determine whether a transaction succeeded and the state changes contained in it were applied. full nodes can provide rpcs to get a transaction return status and value by replaying the transaction, but fast nodes can only do this for nodes after their pivot point, and light nodes cannot do this at all, making a non-consensus solution impractical. instead, we propose to replace the intermediate state root, already obsoleted by eip98, with the return status (1 for success, 0 for failure). this both allows callers to determine success status, and remedies the previous omission of return data from the receipt. specification for blocks where block.number >= byzantium_fork_blknum, the intermediate state root is replaced by a status code, 0 indicating failure (due to any operation that can cause the transaction or top-level call to revert) and 1 indicating success. rationale this constitutes a minimal possible change that permits fetching the success/failure state of transactions, preserving existing capabilities with minimum disruption or additional work for metropolis. copyright copyright and related rights waived via cc0. citation please cite this document as: nick johnson , "eip-658: embedding transaction status code in receipts," ethereum improvement proposals, no. 658, june 2017. [online serial]. available: https://eips.ethereum.org/eips/eip-658. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-2315: simple subroutines for the evm ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🛑 withdrawn standards track: core eip-2315: simple subroutines for the evm two opcodes for efficient, safe, and static subroutines. authors greg colvin (@gcolvin), martin holst swende (@holiman), brooklyn zelenka (@expede), john max skaller created 2019-10-17 discussion link https://ethereum-magicians.org/t/eip-2315-simple-subroutines-for-the-evm/3941 requires eip-3540, eip-3670, eip-4200 table of contents abstract motivation a complete control-flow facility. efficient control-flow. safe control-flow. static control-flow. specification opcodes validity rationale validation alternative designs efficiency costs backwards compatibility test cases simple routine two levels of subroutines failure 1: invalid jump failure 2: shallow return stack subroutine at end of code reference implementation validation function security considerations copyright abstract this proposal provides a complete, efficient, safe and static control-flow facility. it introduces two new opcodes to support calling and returning from subroutines: rjumpsub relative_offset – relative jump to subroutine returnsub – return to pc after most recent rjumpsub. it depends on the two new opcodes proposed by eip-4200 to support static jumps: rjump relative_offset — relative jump to pc + relative_offset rjumpi relative_offset — conditional relative jump it deprecates jump and jumpi, allowing valid code to support streaming, one-pass, and other near-linear compilers. in concert with eip-3540 and eip-3670 it ensures, at initialization time, that valid code will not execute invalid instructions or jump to invalid locations, will not underflow stack, will maintain consistent numbers of inputs and outputs for subroutines, and will have bounded stack height in the absence of recursion. this is among the simplest possible proposals that meets these requirements. motivation a complete control-flow facility. jumps, conditional jumps and subroutines were proposed by alan turing in 1945 as a means of organizing the logic of the code and the design of the memory crystals for his automatic computing engine: we wish to be able to arrange that sequences of orders can divide at various points, continuing in different ways according to the outcome of the calculations to date… we also wish to be able to arrange for the splitting up of operations into subsidiary operations… to start on a subsidiary operation we need only make a note of where we left off the major operation and then apply the first instruction of the subsidiary. when the subsidiary is over we look up the note and continue with the major operation. — alan turing — in b.e. carpenter, r.w. doran, “the other turing machine.” the computer journal, volume 20, issue 3, january 1977. in more contemporary terms, we have sequences of instructions, jumps and conditional jumps that divide sequences into blocks, subroutine calls, and a stack of addresses to return to. the details vary, but similar facilities have proven their value across a long line of important machines over the last 75 years, including most all of the machines we have programmed or implemented – physical machines including the burroughs 5000, cdc 7600, ibm 360, dec pdp-11 and vax, motorola 68000, sun sparc, and intel x86s, as well as virtual machines for scheme, forth, pascal, java, wasm, and others. unlike these machines, the ethereum virtual machine does not provide subroutine operations. instead, they must be synthesized using the dynamic jump instruction, which takes its destination on the stack. further, the evm provides only dynamic jumps, impeding the static analysis we need. efficient control-flow. efficient to write by hand, compile from high level labguages, validate at deploy time, interpret by vms, and compile to machine code. static jumps, conditional jumps, and subroutines are sufficient and efficient in space and time, as shown by historical experience and as we will show for the evm below. safe control-flow. the evm has unusually high requirements for safety. not only do many smart contracts control inordinately large amounts of valuable ether, but once placed on the blockchain any defects are visible to attackers and cannot be repaired. we propose to statically validate important safety constraints on code at initialization time. static control-flow. the evm’s dynamic jumps cause two major problems. first, the need to synthesize static jumps and subroutines with dynamic jumps wastes space and gas with needlessly complex code, as we will show below. worse, jumps that can dynamically branch to any destination in the code can cause quadratic “path explosions” when traversing the flow of control. for ethereum, this is a denial-of-service vulnerability that prevents us, at initialization time, from validating the safe use of evm code and from compiling evm code to machine code. we need static control-flow to validate program safety and to compile evm bytecode to machine code – in time and space linear in the size of the code. specification opcodes rjumpsub (0x5f) relative_offset transfers control to a subroutine. decode the relative_offset from the immediate data at pc. push the current pc + 3 to the return stack. set pc to pc + relative_offset. the relative_offset is relative to the current pc. the offset is encoded as a two-byte, twos-complement signed integer, stored msb-first. the gas cost is low. returnsub (0x5e) returns control to the caller of a subroutine. pop the return stack to pc. the gas cost is verylow. notes: values popped off the return stack do not need to be validated, since they are alterable only by rjumpsub and returnsub. the description above lays out the semantics of these instructions in terms of a return stack. but the actual state of the return stack is not observable by evm code or consensus-critical to the protocol. (for example, a node implementer may code rjumpsub to unobservably push pc on the return stack rather than pc + 1, which is allowed so long as returnsub observably returns control to the pc + 3 location.) validity execution is defined in the yellow paper as a sequence of changes in the evm state. the conditions on valid code are preserved by state changes. at runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state. the yellow paper defines six such states. insufficient gas more than 1024 stack items state modification during a static call insufficient stack items invalid jump destination invalid instruction we would like to consider evm code valid iff no execution of the program can lead to an exceptional halting state. in practice, we must test at runtime for the first three conditions. we don’t know how much gas there will be, we don’t know how deep a recursion may go, analysis of stack depth even for non-recursive programs is nontrivial, and we don’t know whether a call will be static. all of the remaining conditions must be validated statically, in time and space quasi-linear in the size of the code. static constraints on valid code every instruction must be valid: the jump and jumpi instructions are not valid. every jump must be valid: the rjump, rjumpi, or rjumpsub instructions must not address immediate data or addresses outside of their code section. the stacks must be valid: the number of items on the data stack must always be positive. the number of items on the return stack must always be positive. the data stack must be consistently aligned: the data stack height is the absolute difference between the current stack pointer and the stack pointer on entry to the current subroutine. it must be the same for every reachable path through a given pc and must not exceed 1024. rationale this is a purely semantic specification, placing no constraints on the syntax of code sections beyond being a sequence of opcodes and immediate data – a subroutine is not a contiguous sequence of bytecode, it is a subgraph of the bytecode’s control-flow graph. the evm is a simple state machine. we only promise that valid code will not, as it were, jam up the gears of the machine. by avoiding syntactic constraints we allow for optimizations like tail call elimination, multiple-entry subroutines, moving “cold” code out of line, and other ways of reducing redundancy and keeping “hot” code in cache. since we wish to support one-pass compilation of evm code to machine code it is crucial that the evm code be as well optimized as possible up front. validation rather than enforce constraints via syntax, we enforce them via validation. the constraints on valid code cover all of the exceptional halting states that we can validate and allow code to be validated and compiled in time and space quasi-linear in the size of the code. the rjump, rjumpi and rjumpsub instructions take their relative_offset as immediate arguments, which cannot change at runtime. having constant destinations for all jumps means that all jump destinations can be validated at initialization time, not runtime. dynamic jumps can branch to any destination in the code, so exploitable quadratic “path explosions” are possible when traversing the control flow graph. deprecating jump and jumpi prevents this. requiring a consistently aligned data stack prevents stack underflow ensures that all calls to a subroutine have the same number of inputs and the same number of outputs and ensures that stack height is bounded in the absence of recursion. requiring a consistently aligned data stack also allows some algorithms that traverse the control-flow graph – including code validation and compilation – to break cycles at joins, again preventing quadratic path explosion. when a traversal gets to a pc it has visited before it is either at the beginning of a loop or the entry to a function. since the stack height at that pc is constant we know that loops will not grow stack, and that the number of arguments to a subroutine will always be the same – there may be no need to traverse that path again. note: the jvm and wasm enforce similar constraints for similar reasons. alternative designs there are a few major designs for a subroutine facility, two of which are considered here. the others are mostly not appropriate for the evm, such as the wheeler jump – self-modifying code that writes return addresses into called subroutines. 1. keep return addresses on a dedicated return stack. turing’s design is often used by stack machines, including those for forth, java, wasm, and others. the data stack is used for computation, with a dedicated stack for return addresses. a single instruction suffices to call, and another to return from a routine. 2. keep return addresses on the data stack. this design is often used by register machines, including those from cdc, ibm, dec, intel, and arm. the registers are used primarily for computation, and the stack maintains call frames for return addresses, arguments, and local variables. on the evm there are no registers for computation, so using the stack for both purposes can cause the sort of inefficiencies we see below. pascal p-code does use this design, but as part of a complex calling convention with dedicated registers. we prefer the dedicated return stack. it maintains a clear separation between calculation and flow of control: the data stack is free of vulnerable return addresses and it’s impossible to overwrite the return stack. it improves efficiency: it uses native arithmetic rather than 256-bit evm instructions for the return address, doesn’t use up a data stack slot for the return address and needs less motion of 256-bit data on the stack. efficiency we illustrate here how subroutine instructions can be used to reduce the complexity and gas costs of both ordinary and optimized subroutine calls compared to using jump. simple subroutine call consider these examples of a fairly minimal subroutine, including the code to call it. subroutine call, using rjumpsub: square: dup1 ; 3 gas mul ; 5 gas returnsub ; 3 gas call_square: push 0x02 ; 3 gas rjumpsub square ; 5 gas total gas: 19 subroutine call, using jump: square: jumpdest ; 1 gas swap1 ; 3 gas dup1 ; 3 gas mul ; 5 gas swap1 ; 3 gas jump ; 8 gas call_square: jumpdest ; 1 gas push 0x02 ; 3 gas push rtn_call: ; 3 gas push square ; 3 gas jump ; 8 gas rtn_call: jumpdest ; 1 gas total: 41 gas. using rjumpsub versus jump saves 41 19 = 22 gas — a 54% improvement. tail call optimization of course in cases like this one we can optimize the tail call, so that the return from square actually returns from test_square. tail call optimization, using rjumpsub and returnsub: dup1 ; 3 gas mul ; 5 gas returnsub ; 3 gas call_square: push 0x02 ; 3 gas rjump square ; 3 gas total: 17 gas tail call optimization, using jump: square: jumpdest ; 1 gas swap1 ; 3 gas dup1 ; 3 gas mul ; 5 gas swap2 ; 3 gas jump ; 8 gas call_square: jumpdest ; 1 gas push 0x02 ; 3 gas push square ; 3 gas jump ; 8 gas total: 38 gas using rjumpsub versus jump saves 38 17 = 21 gas — a 55% improvement. efficiency caveats we can see that these instructions provide a simpler and more gas-efficient subroutine mechanism than using jump — in our examples they cut gas use by about half. clearly, the benefits of this efficiency are greater for programs that have been factored into smaller subroutines. how small? wrapping code in a subroutine costs only 8 gas using rjumpsub and returnsub versus 30 gas using jump, push and swap as above. costs the low cost of rjumpsub versus the mid cost of jump is justified by needing only to decode the immediate two byte destination to the pc and push the return address on the return stack, all using native arithmetic, versus using the data stack with emulated 256-bit instructions. the verylow cost of returnsub is justified by needing only to pop the return stack into the pc. benchmarking will be needed to tell if the costs are well-balanced. backwards compatibility these changes affect the semantics of existing evm code: bytes that would have been interpreted as valid jump destinations may now be interpreted as immediate data. since this proposal depends on the ethereum object format to signal the change this is not a practical issue. test cases simple routine this should jump into a subroutine, back out and stop. bytecode: 0x5f0003005e (rjumpsub 3, returnsub, stop) pc op cost stack rstack 0 rjumpsub 5 [] [] 2 stop 0 [] [] 3 returnsub 3 [] [] output: 0x consumed gas: 10 two levels of subroutines this should execute fine, going into one two depths of subroutines bytecode: 0x5f00045f00025200 (rjumpsub 4, rjumpsub 2, returnsub, returnsub, stop) pc op cost stack rstack 0 rjumpsub 5 [] [] 3 rjumpsub 5 [] [] 4 returnsub 5 [] [] 5 returnsub 5 [] [] 6 stop 0 [] [] consumed gas: 20 failure 1: invalid jump this should fail, since the given location is outside of the code-range. bytecode: 0x5fff(rjumpsub -1) pc op cost stack rstack 0 rjumpsub 10 [] [] error: at pc=0, op=rjumpsub: invalid jump destination failure 2: shallow return stack this should fail at first opcode, due to shallow return_stack bytecode: 0x5e (returnsub) pc op cost stack rstack 0 returnsub 5 [] [] error: at pc=0, op=returnsub: invalid retsub subroutine at end of code in this example the rjumpsub is on the last byte of code. when the subroutine returns, it should hit the ‘virtual stop’ after the bytecode, and not exit with error bytecode: 0x5c00045e5fffff (rjump 4, returnsub, rjumpsub -1) pc op cost stack rstack 0 rjump 5 [] [] 3 returnsub 5 [] [] 4 rjumpsub 5 [] [] 7 stop 0 [] [] consumed gas: 15 reference implementation the following is a pseudo-python implementation of an algorithm for predicating code validity. an equivalent algorithm must be run at initialization time. this algorithm performs a symbolic execution of the program that recursively traverses the code, emulating its control flow and stack use and checking for violations of the rules above. it runs in time equal to o(vertices + edges) in the program’s control-flow graph, where edges represent control flow and the vertices represent basic blocks — thus the algorithm takes time proportional to the size of the code. it maintains a stack of continuations for conditional jumps, the size of which is at most proportional to the size of the code. validation function ** note: this function is known to be incomplete and incorrect. ** for simplicity’s sake we assume that all jumpdest analysis and prior validation has been done, including eip-3540, eip-3670, and eip-4200, so eof headers and sections are well-formed, and there are no invalid instructions or jumps. in practice, all passes of validation can be folded into a single loop no recursion. we also assume some helper functions. is_valid(opcode) returns true iff opcode is valid. is_terminator(opcode) returns true iff opcode is terminator. is_valid_jumpdest(pc) returns true iff pc is a valid jump destination. immediate_data(pc) returns the immediate data for the instruction at pc. immediate_size(opcode) returns the size of the immediate data for an opcode. removed_items(opcode) returns the number of items removed from the data_stack by the opcode. added_items(opcode) returns the number of items added to the data_stack by the opcode. # returns true iff code is valid def validate_code(code: bytes, pc: int, sp: int, bp: int) -> boolean: continuations = [] do while pc < len(code): opcode = code[pc] if !is_valid(opcode): return false if is_terminator(opcode): return true # check stack height and return if we have been here before stack_height = sp bp if stack_height > 1024 return false if pos in stack_heights: if stack_height != stack_heights[pos]: return false return true else: stack_heights[pos] = stack_height if opcode == rjump: # reset pc to destination of jump jumpdest = immediate_data(pc) pc += jumpdest if !is_valid_jumpdest(pc) return false elif opcode == rjumpi: jumpdest = pc + immediate_data(pc) if !is_valid_jumpdest(pc) return false # continue true side of conditional later continations.push((jumpdest, sp, bp)) # continue false side of conditional now elif opcode == rjumpsub: # will enter subroutine at destination bp = sp # push return address and reset pc to destination jumpdest = pc + immediate_data(pc) if !is_valid_jumpdest(pc) return false push(return_stack, pc + 3) pc = jumpdest continue elif opcode == returnsub: # will return to subroutine at destination bp = sp # pop return address and check for preceding call pc = pop(return_stack) if code[pc 3] != rjumpsub: return false # apply instructions to stack sp -= removed_items(opcode) if sp < 0 return false sp += added_items(opcode) # skip opcode and immediate data pc += 1 + immediate_size(opcode) while (pc, sp, bp) = continuations.pop() return true security considerations these changes introduce new flow control instructions. they do not introduce any new security considerations. this eip is intended to improve security by validating a higher level of safety for evm code deployed on the blockchain. the validation algorithm must be quasi-linear in time and space to not be a denial of service vulnerability. the algorithm here makes one linear-time pass of the bytecode, and uses a stack of continuations that cannot exceed the number of rjumpi instructions in the code. copyright copyright and related rights waived via cc0. citation please cite this document as: greg colvin (@gcolvin), martin holst swende (@holiman), brooklyn zelenka (@expede), john max skaller , "eip-2315: simple subroutines for the evm [draft]," ethereum improvement proposals, no. 2315, october 2019. [online serial]. available: https://eips.ethereum.org/eips/eip-2315. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-3709: remove support for type 1 transactions ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-3709: remove support for type 1 transactions authors gregory markou (@gregthegreek) created 2021-08-07 discussion link https://ethereum-magicians.org/t/eip-3709-deprecate-type-1-transactions/6810 requires eip-1559 table of contents simple summary abstract motivation specification rationale security considerations copyright simple summary deprecates usage of eip-2718 transactiontype 1 in wallets and providers, upgrading all type 1 transactions to a type 2 transaction. abstract since both transactiontype 1 and 2 contain access_list, we propose the removal of offering transactiontype 1 from wallets and providers, instead the transaction will be converted to transactiontype 2 to make use of the new gas properties introduced by eip-1559. motivation eip-2930 was introduced as the first transactiontype, type 1, with the intention of adding access_list to the transactionpayload. eip-1559 introduced the second transactiontype 2, which is represented as rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, amount, data, access_list, signature_y_parity, signature_r, signature_s]). the intention behind eip-1559 was to enhance the user experience surrounding gas fees, and as we move forward we expect that the majority of the network will begin to using transactiontype 2 instead of the legacy style transactions. transactiontype 1 is a legacy transaction with the addition of access_list meaning that users will not benefit from enhancements made by eip-1559. transactiontype 2 contains access_list, thus there is no reason to further support transactiontype 1 if the end goal is to push users towards using transactiontype 2 anyway. specification for wallets and providers, if a user submits a transaction for signing with where transactiontype == 0x1, the developer should upgrade the transaction to meet the criteria of transaction of type 2. the following fields need to be changed, or amended: access_list: nothing changes and it should remain in the transaction. type: should change from 0x1 to 0x2. gas_price: should be removed in favour of max_fee_per_gas & max_priority_fee_per_gas (see eip-1559 for proper usage). rationale improve the user experience for submitting transactions, and move away from legacy style transactions. security considerations there are no known security considerations at this time. copyright copyright and related rights waived via cc0. citation please cite this document as: gregory markou (@gregthegreek), "eip-3709: remove support for type 1 transactions [draft]," ethereum improvement proposals, no. 3709, august 2021. [online serial]. available: https://eips.ethereum.org/eips/eip-3709. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. erc-5192: minimal soulbound nfts ethereum improvement proposals allcorenetworkinginterfaceercmetainformational standards track: erc erc-5192: minimal soulbound nfts minimal interface for soulbinding eip-721 nfts authors tim daubenschütz (@timdaub), anders (@0xanders) created 2022-07-01 requires eip-165, eip-721 table of contents abstract motivation specification contract interface rationale backwards compatibility security considerations copyright abstract this standard is an extension of eip-721. it proposes a minimal interface to make tokens soulbound using the feature detection functionality of eip-165. a soulbound token is a non-fungible token bound to a single account. motivation the ethereum community has expressed a need for non-transferrable, non-fungible, and socially-priced tokens similar to world of warcraft’s soulbound items. but the lack of a token standard leads many developers to simply throw errors upon a user’s invocation of transfer functionalities. over the long term, this will lead to fragmentation and less composability. in this document, we outline a minimal addition to eip-721 that allows wallet implementers to check for a token contract’s permanent (non-)transferability using eip-165. specification the keywords “must”, “must not”, “required”, “shall”, “shall not”, “should”, “should not”, “recommended”, “may” and “optional” in this document are to be interpreted as described in rfc 2119. contract interface a token with a uint256 tokenid may be bound to a receiving account with function locked(...) returning true. in this case, all eip-721 functions of the contract that transfer the token from one account to another must throw. // spdx-license-identifier: cc0-1.0 pragma solidity ^0.8.0; interface ierc5192 { /// @notice emitted when the locking status is changed to locked. /// @dev if a token is minted and the status is locked, this event should be emitted. /// @param tokenid the identifier for a token. event locked(uint256 tokenid); /// @notice emitted when the locking status is changed to unlocked. /// @dev if a token is minted and the status is unlocked, this event should be emitted. /// @param tokenid the identifier for a token. event unlocked(uint256 tokenid); /// @notice returns the locking status of an soulbound token /// @dev sbts assigned to zero address are considered invalid, and queries /// about them do throw. /// @param tokenid the identifier for an sbt. function locked(uint256 tokenid) external view returns (bool); } to aid recognition that an eip-721 token implements “soulbinding” via this eip upon calling eip-721’s function supportsinterface(bytes4 interfaceid) external view returns (bool) with interfaceid=0xb45a3c0e, a contract implementing this eip must return true. rationale the above model is the simplest possible path towards a canonical interface for soulbound tokens. it reflects upon the numerous soulbound token implementations that simply revert upon transfers. backwards compatibility this proposal is fully backward compatible with eip-721. security considerations there are no security considerations related directly to the implementation of this standard. copyright copyright and related rights waived via cc0. citation please cite this document as: tim daubenschütz (@timdaub), anders (@0xanders), "erc-5192: minimal soulbound nfts," ethereum improvement proposals, no. 5192, july 2022. [online serial]. available: https://eips.ethereum.org/eips/eip-5192. ethereum improvement proposals ethereum improvement proposals ethereum/eips ethereum improvement proposals (eips) describe standards for the ethereum platform, including core protocol specifications, client apis, and contract standards. eip-107: safe "eth_sendtransaction" authorization via html popup ethereum improvement proposals allcorenetworkinginterfaceercmetainformational 🚧 stagnant standards track: interface eip-107: safe "eth_sendtransaction" authorization via html popup authors ronan sandford (@wighawag) created 2016-06-05 table of contents abstract motivation account unlocked account locked and no “personal” api exposed via rpc: account locked but node exposing the “personal” api via rpc : specification rationale implementations copyright abstract this draft eip describes the details of an authorization method that if provided by rpc enabled ethereum nodes would allow regular websites to send transactions (via eth_sendtransaction) without the need to enable cors. instead, user would be asked to confirm the transaction via an html popup. every read only rpc call the dapp wants to perform is redirected to an invisible iframe from the node’s domain and for every transaction that the dapp wish to execute, an html popup is presented to the user to allow him/her to cancel or confirm the transaction. this allows the dapp to connect to the node’s rpc api without being granted any kind of privileges. this allows users to safely interact with dapps running in their everyday web browser while their accounts are unlocked. in case the account is not unlocked, and the node has allowed the “personal” api via rpc,the html page also allow the user to enter their password to unlock the account for the scope of the transaction. motivation currently, if a user navigates to a dapp running on a website using her/his everyday browser, the dapp will by default have no access to the rpc api for security reasons. the user will have to enable cors for the website’s domain in order for the dapp to work. unfortunately if the user does so, the dapp will be able to send transactions from any unlocked account without the need for any user consent. in other words, not only does the user need to change the node’s default setting, but the user is also forced to trust the dapp in order to use it. this is of course not acceptable and forces existing dapps to rely on the use of workarounds like: if the transaction is a plain ether transfer, the user is asked to enter it in a dedicated trusted wallet like “mist” for more complex case, the user is asked to enter the transaction manually via the node command line interface. this proposal aims to provide a safe and user friendly alternative. here are some screenshots of the provided implementation of that html popup: account unlocked when the account is already unlocked, the user is presented with the following popup for every transaction that the dapp attempts to make: account locked and no “personal” api exposed via rpc: when the account is locked, and the node does not provide access to account unlocking via its rpc interface, the following popup will be presented. this is not ideal since this requires the user to know how to unlock an account: account locked but node exposing the “personal” api via rpc : a better option is to ask the user for their password, but this is only possible if the node allows access to the “personal” api via rpc. in such case, the following dialog will be presented to the user so he/she can accept the transaction by providing the password required to unlock the account: specification in order for the mechanism to work, the node needs to serve an html file via http at the url /authorization.html this file will then be used by the dapp in 2 different modes (invisible iframe and popup window). the invisible iframe will be embedded in the dapp to allow the dapp to send its read-only rpc call without having to enable cors for the dapp’s website domain. this is done by sending message to the iframe (via javascript window.postmessage) which in turn execute the rpc call. this works since the iframe and the node share the same domain/port. in the iframe mode, the html file’s javascript code will ensure that no call requiring an unlocked key can be made. this is to prevent dapps from embedding the invisible iframe and tricking the user into clicking the confirm button. if the dapp requires an eth_sendtransaction call, the dapp will instead open a new window using the same url. in this popup window mode, the html file’s javascript code will allow eth_sendtransaction (but not eth_sign, as there is no way to display to the user the meaningful content of the transaction to sign in a safe way) to be called. but instead of sending the call to the node directly, a confirmation dialog will be presented showing the sender and recipient addresses, as well as the amount being transferred along with the potential gas cost. upon the user approving, the request will be sent and the result returned to the dapp. an error will be returned in case the user cancel the request. the html page also checks for the availability of the “personal” api and if so, will ask the user to unlock the account if necessary. the unlocking is temporary (3s) so the password will be asked again if a transaction is attempted before the end of this short time. in both iframe mode and window mode, the communication with the dapp is achieved using window.postmessage. the fist message the iframe/window sends is a message containing the string “ready” to let the dapp know that it now accepts messages. then the dapp can start performing rpc call by sending message using the following object : { id:, //so responses can be match as there is no guarantee of the order of the response payload: //this is the exact object that usually send to the node } for eth_sendtransaction the “gas”, “gasprice” and “from” field need to be set in the rpc parameter so that the window can display the correct value. if not all of these are passed in, the window will return an error. upon receiving such message, the iframe will perform the actual rpc call to the node but only if such a call is a read only call (not requiring an unlocked key). if it is not it will return a error. the window on the other will only accept eth_sendtransaction calls but will display a dialog so the user can accept or cancel the request. in all the cases, the iframe/window will send a message back to the dapp using the following object: { id:, result:, error: } the error object cannot be a javascript error object due to postmessage limitation. instead it is { message:, type: //type="cancel" means the user cancel the transaction } rationale the design for that proposal was chosen for its simplicity and security. a previous idea was to use an oauth-like protocol in order for the user to accept or deny a transaction request. it would have required deeper code change in the node and some geth contributors argues that such change did not fit into geth code base as it would have required dapp aware code. the current design, instead has a very simple implementation (self contained html file that can be shared across node’s implementation) and its safeness is guarantess by browsers’ cross domain policies. the use of iframe/ window was required to have both security and user friendliness. the invisible iframe allows the dapp to execute read only calls without the need for user input, and the window ensures user approval before making a call. while we could have made it without the window mode by making the iframe confirmation use the native browser window.confirm dialog, this would have prevented the use of a more elegant confirmation popup that the current design allows. it also happens to be that the window.confirm is not safe in some browsers, as it gives focus to the accept option and can be triggered automatically (https://bugs.chromium.org/p/chromium/issues/detail?id=260653). implementations in order to implement this design, the following html file or an equivalent one needs to be served at the url /authorization.html that’s it. ethereum authorization

please wait...