Skip to content

Releases: neonlabsorg/neon-evm

Mainnet v1.14.0

17 Jun 13:10
Compare
Choose a tag to compare
  • 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

23 Mar 20:48
Compare
Choose a tag to compare

What's Changed

Devnet v1.7.0

01 Dec 08:28
Compare
Choose a tag to compare
  • 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’s CHAIN_ID; with this update it returns the chain’s CHAIN_ID.
      • An EOA CHAIN_ID is specified in the transaction
      • A contract’s CHAIN_ID is the same as the CHAIN_ID of its creator
    • EnablesCHAIN_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

19 Oct 11:29
552ba4c
Compare
Choose a tag to compare
  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.
  2. Solana state optimizations: Optimizes Solana state changes by minimizing API requests. Multiple alterations for a single Solana account are condensed into one state change.
  3. Precompiled contracts utilization: Incorporates the functionality to utilize precompiled contracts through the emulator, enabling proxies to directly invoke eth_call.
  4. Additional provisions in Solidity and Viper contracts: Adds provisions for block.timestamp and block.number in Solidity and Viper contracts for CREATE2 instruction and mapping indices. Implementation is required on the Neon Proxy end.
  5. 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

11 Sep 22:14
9371590
Compare
Choose a tag to compare
  • 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

08 Sep 13:51
Compare
Choose a tag to compare
  • 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

14 Aug 22:14
6d0364c
Compare
Choose a tag to compare
  • 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

04 Aug 17:14
Compare
Choose a tag to compare
  • 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.