Releases: neonlabsorg/neon-evm
Releases · neonlabsorg/neon-evm
Mainnet v1.14.0
- Change the pessimistic blocking of accounts to the optimistic execution of Ethereum-like transactions
- Remove blocking of the whole contract storage, and include only accounts with used contracts cells into Solana transactions
- Implement multi-token payments
- Implement compatibility layer with Solana programs
Devnet v1.11.2
What's Changed
- NDEV-2176: Change the ordering of data in neon_revision by @Deniskore in #189
- NDEV-2175: Use tracing::instrument and request id on neon-api endpoints by @andreisilviudragnea in #188
- NDEV-2184: Report error when requested too early slot by @andreisilviudragnea in #195
- NDEV-2204: Use global RPC clients by @andreisilviudragnea in #194
- NDEV-2226 Remove emulate-hash, trace-hash and trace-next-block by @anton-lisanin in #196
- NDEV-2183: Implement get_sync_status for eth_syncing by @Deniskore in #193
- NDEV-2222: Add build-info to neon-cli and neon-api by @andreisilviudragnea in #200
- NDEV-2043: Improve performance of neon-api crate by @andreisilviudragnea in #158
- NDEV-2252: Clean up tracer implementation by @andreisilviudragnea in #208
- Multiple bug fixes: NDEV-2330, NDEV-2343, NDEV-2344, NDEV-2345 by @andreisilviudragnea in #220
- NDEV-1859 Multiple tokens by @anton-lisanin in #201
- NDEV-2309: Implement NEON_REVISION caching by @Deniskore in #226
- NDEV-2332: Decouple tracer code from evm-loader to neon-lib crate by @andreisilviudragnea in #232
- Use solana-test-validator for the CI by @anton-lisanin in #239
- NDEV-2403: Decouple Rpc trait from Solana RpcClient by @andreisilviudragnea in #233
- NDEV-2374: Fixes for tracer-api multiple tokens support by @andreisilviudragnea in #242
- NDEV-2438: Simplify Rpc trait usage by @andreisilviudragnea in #245
- NDEV-2439: Replace HexBytes with web3::types::Bytes by @andreisilviudragnea in #246
- NDEV-2441: Remove type parameter duplication in precompile_extension module by @andreisilviudragnea in #247
- NDEV-2504: Remove operator's priority by @anton-lisanin in #257
- NDEV-2514: Refactor get_config module by @andreisilviudragnea in #255
- NDEV-2505 Fix EXTHASHCODE by @mickvangelderen in #253
- NDEV-2620: Add executor_state: &impl Database parameter to EventListener::event method by @andreisilviudragnea in #273
- NDEV-2651 Remove syscall_stabs by @s-medvedev in #279
- Add Account Revision by @anton-lisanin in #276
- NDEV-2673 Fix account migration from before revision by @anton-lisanin in #285
- Update Solana SDK to v1.17 by @anton-lisanin in #286
- Remove GetLargestAccounts RPC request by @anton-lisanin in #271
- Add additional check for data out of bounds in get_elf_parameter by @Deniskore in #289
- NDEV-2721: Update Solana to v1.17.24 by @andreisilviudragnea in #293
Devnet v1.7.0
- Supports alternative tokens for gas payment
- Changes codes for Neon transaction processing
- Updates the internal account structure to support multiple “native” tokens
- Updates the holder account structures to support multiple “native” tokens
- Changes the logic of opcode
CHAIN_ID
; previously, it returned a caller’sCHAIN_ID
; with this update it returns the chain’sCHAIN_ID
.- An EOA
CHAIN_ID
is specified in the transaction - A contract’s
CHAIN_ID
is the same as theCHAIN_ID
of its creator
- An EOA
- Enables
CHAIN_ID
245022927. This enables transactions to use wrapped SOL instead of NEON as a native token
- Implements EIP-6780: SELFDESTRUCT only in the same transaction
Mainnet v1.4.1
- Memory-usage enhancements: Implements memory-usage enhancements for deep call stacks in Solidity and Viper contracts. This modification enables dApps to operate with call stacks exceeding seven contracts.
- Solana state optimizations: Optimizes Solana state changes by minimizing API requests. Multiple alterations for a single Solana account are condensed into one state change.
- Precompiled contracts utilization: Incorporates the functionality to utilize precompiled contracts through the emulator, enabling proxies to directly invoke
eth_call
. - Additional provisions in Solidity and Viper contracts: Adds provisions for
block.timestamp
andblock.number
in Solidity and Viper contracts forCREATE2
instruction and mapping indices. Implementation is required on the Neon Proxy end. - EIP-2930 support: Integrates support for [EIP-2930](https://eips.ethereum.org/EIPS/eip-2930), which accommodates the latest Ethereum transactions with access lists. For more details, refer to the [Ethereum documentation](https://eips.ethereum.org/EIPS/eip-2930). Implementation is required on the Neon Proxy end.
Devnet v1.5.0
- Critical Vulnerability Mitigation: This release addresses a critical vulnerability that previously posed a risk of unauthorized access to Operator assets. To mitigate this, a new verification step has been introduced during the creation of Holder accounts. These accounts can now only be generated using the CreateWithSeed(base, seed, programId) approach. Notably, the format of the HolderCreate instruction has been modified, incorporating seed-based data and its length. This change aligns with the system instruction SystemProgram::CreateAccountWithSeed. The potential attack scenario involved intercepting accounts created by Neon EVM during iterative transactions, particularly accounts designed to accommodate extensive contracts deployed within a transaction. Neon EVM now expands the size of these accounts over multiple Solana transactions due to the platform's 10kB resizing limitation for PDA accounts. The attacker's strategy included specifying instructions for creating a Holder account once the account exists but remains uninitialized, allowing them to withdraw the stored LAMPORTs after closing the account.
- Solidity/Viper Contract Support: This release adds support for block.timestamp and block.number in Solidity/Viper contracts for the CREATE2 instruction and mapping indexes. Please note that this change requires corresponding implementation on the Neon Proxy side.
- Solana State Optimization: Significant optimizations have been made for applying changes to the Solana state. This improvement minimizes the number of requests to the Solana state by consolidating multiple changes for one Solana account into a single change in the Solana state.
- Precompiled Contracts in Emulator: Neon EVM now allows the use of precompiled contracts from the emulator. This enables a proxy to make direct calls to precompiled contracts in eth_call.
- EIP-2930 Support: The release incorporates support for EIP-2930, which introduces the new version of Ethereum transactions with access lists. For further details, please refer to the Ethereum documentation. Note that this change necessitates implementation on the Neon Proxy side.
Mainnet v1.2.0
- Critical Vulnerability Mitigation: Addresses a critical vulnerability that could lead to the unauthorized access of Operator assets. This release introduces a new verification step during the creation of Holder accounts. These accounts can now only be generated using the CreateWithSeed(base, seed, programId) approach. It is vital to note that the format of the HolderCreate instruction has undergone modifications, with the addition of seed-based data and its length. This binary data structure aligns with the system instruction SystemProgram::CreateAccountWithSeed. The potential attack scenario involves intercepting accounts created by Neon EVM during iterative transactions. Specifically, accounts are are designed to accommodate extensive contracts deployed during a transaction. Neon EVM expands the size of these accounts over multiple Solana transactions due to the platform’s 10kB resizing limitation for PDA accounts. The attacker’s strategy involves specifying instructions for creating a Holder account once the account exists but remains uninitialized. This allows them to withdraw the stored LAMPORTs after closing the account.
Mainnet v1.0.1
- Added implementation of EIP-3855 - support of ‘PUSH0’ opcode, present in the new versions of Solidity compilers >= v0.8.20
- Added operator keys for ByBit and Gate CEXs. The reason is to provide the test environment for the integration of withdrawing NEON tokens directly to Neon EVM, instead of Solana.
- Enhanced the neon-cli utility by incorporating Solana account caching. This strategic enhancement markedly reduces response times for intricate transactions necessitating multiple accounts.
Devnet v1.1.1
- Added implementation of EIP-3855 - support of ‘PUSH0’ opcode, present in the new versions of Solidity compilers >= v0.8.20
- Added operator keys for ByBit and Gate CEXs. The reason is to provide the test environment for the integration of withdrawing NEON tokens directly to Neon EVM, instead of Solana.