1. 21 Apr, 2023 1 commit
  2. 30 Mar, 2023 1 commit
  3. 09 Mar, 2023 1 commit
    • Roberto Bayardo's avatar
      core, core/types: plain Message struct (#25977) · 67ac5f0a
      Roberto Bayardo authored
      Here, the core.Message interface turns into a plain struct and
      types.Message gets removed.
      
      This is a breaking change to packages core and core/types. While we do
      not promise API stability for package core, we do for core/types. An
      exception can be made for types.Message, since it doesn't have any
      purpose apart from invoking the state transition in package core.
      types.Message was also marked deprecated by the same commit it
      got added in, 4dca5d4d (November 2016).
      
      The core.Message interface was added in December 2014, in commit
      db494170, for the purpose of 'testing' state transitions. It's the
      same change that made transaction struct fields private. Before that,
      the state transition used *types.Transaction directly.
      
      Over time, multiple implementations of the interface accrued across
      different packages, since constructing a Message is required whenever
      one wants to invoke the state transition. These implementations all
      looked very similar, a struct with private fields exposing the fields
      as accessor methods.
      
      By changing Message into a struct with public fields we can remove all
      these useless interface implementations. It will also hopefully
      simplify future changes to the type with less updates to apply across
      all of go-ethereum when a field is added to Message.
      
      ---------
      Co-authored-by: 's avatarFelix Lange <fjl@twurst.com>
      67ac5f0a
  4. 16 Nov, 2022 1 commit
  5. 30 Jun, 2021 1 commit
  6. 17 May, 2021 1 commit
  7. 25 Feb, 2021 1 commit
    • lightclient's avatar
      all: add support for EIP-2718, EIP-2930 transactions (#21502) · bbfb1e40
      lightclient authored
      This adds support for EIP-2718 typed transactions as well as EIP-2930
      access list transactions (tx type 1). These EIPs are scheduled for the
      Berlin fork.
      
      There very few changes to existing APIs in core/types, and several new APIs
      to deal with access list transactions. In particular, there are two new
      constructor functions for transactions: types.NewTx and types.SignNewTx.
      Since the canonical encoding of typed transactions is not RLP-compatible,
      Transaction now has new methods for encoding and decoding: MarshalBinary
      and UnmarshalBinary.
      
      The existing EIP-155 signer does not support the new transaction types.
      All code dealing with transaction signatures should be updated to use the
      newer EIP-2930 signer. To make this easier for future updates, we have
      added new constructor functions for types.Signer: types.LatestSigner and
      types.LatestSignerForChainID. 
      
      This change also adds support for the YoloV3 testnet.
      Co-authored-by: 's avatarMartin Holst Swende <martin@swende.se>
      Co-authored-by: 's avatarFelix Lange <fjl@twurst.com>
      Co-authored-by: 's avatarRyan Schneider <ryanleeschneider@gmail.com>
      bbfb1e40
  8. 13 Nov, 2020 1 commit
  9. 22 Apr, 2020 1 commit
    • gary rong's avatar
      all: seperate consensus error and evm internal error (#20830) · b9df7ecd
      gary rong authored
      * all: seperate consensus error and evm internal error
      
      There are actually two types of error will be returned when
      a tranaction/message call is executed: (a) consensus error
      (b) evm internal error. The former should be converted to
      a consensus issue, e.g. The sender doesn't enough asset to
      purchase the gas it specifies. The latter is allowed since
      evm itself is a blackbox and internal error is allowed to happen.
      
      This PR emphasizes the difference by introducing a executionResult
      structure. The evm error is embedded inside. So if any error
      returned, it indicates consensus issue happens.
      
      And also this PR improve the `EstimateGas` API to return the concrete
      revert reason if the transaction always fails
      
      * all: polish
      
      * accounts/abi/bind/backends: add tests
      
      * accounts/abi/bind/backends, internal: cleanup error message
      
      * all: address comments
      
      * core: fix lint
      
      * accounts, core, eth, internal: address comments
      
      * accounts, internal: resolve revert reason if possible
      
      * accounts, internal: address comments
      b9df7ecd
  10. 25 Feb, 2020 2 commits
  11. 01 Apr, 2019 1 commit