cerc-io/laconicd-deprecated
19
0
Fork 1
Code Issues 21 Pull Requests Actions Packages Projects Releases 3 Wiki Activity

Update tx spec doc

Browse Source
This commit is contained in:
Aleksandr Bezobchuk 2018-08-24 08:46:58 -07:00
parent 7d4b3ef51e
commit e99e02908f
1 changed files with 16 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
docs/spec/transactions/README.md
View File

@ -6,34 +6,20 @@ and subject to change.
## Routing ## Routing
Ethermint needs to parse and handle transactions routed for both the EVM and for Ethermint needs to parse and handle transactions routed for both the EVM and for
the Cosmos hub. We attempt to achieve this by mimicking [Geth's](https://github.com/ethereum/go-ethereum) `Transaction` structure and utilizing the Cosmos hub. We attempt to achieve this by mimicking [Geth's](https://github.com/ethereum/go-ethereum) `Transaction` structure to handle
the `Payload` as the potential encoding of a Cosmos-routed transaction. What Ethereum transactions and utilizing the SDK's `auth.StdTx` for Cosmos
designates this encoding, and ultimately routing, is the `Transaction.Recipient` transactions. Both of these structures are registered with an [Amino](https://github.com/tendermint/go-amino) codec, so the `TxDecoder` that in invoked
address -- if this address matches some global unique predefined and configured during the `BaseApp#runTx`, will be able to decode raw transaction bytes into the
address, we regard it as a transaction meant for Cosmos, otherwise, the transaction appropriate transaction type which will then be passed onto handlers downstream.
is a pure Ethereum transaction and will be executed in the EVM.
For Cosmos routed transactions, the `Transaction.Payload` will contain an __Note__: Our goal is to utilize Geth as a library, at least as much as possible,
embedded encoded type: `EmbeddedTx`. This structure is analogous to the Cosmos so it should be expected that these types and the operations you may perform on
SDK `sdk.StdTx`. If a client wishes to send an `EmbeddedTx`, it must first encode them will keep in line with Ethereum (e.g. signature algorithms and gas/fees).
the embedded transaction, and then encode the embedding `Transaction`.
__Note__: The `Transaction` and `EmbeddedTx` types utilize the [Amino](https://github.com/tendermint/go-amino) object serialization protocol and as such,
the `Transaction` is not an exact replica of what will be found in Ethereum. Our
goal is to utilize Geth as a library, at least as much as possible, so it should
be expected that these types and the operations you may perform on them will keep
in line with Ethereum.
Being that Ethermint implements the ABCI application interface, as transactions
are sent they are passed through a series of handlers. Once such handler, `runTx`,
is responsible for invoking the `TxDecoder` which performs the business logic of
properly deserializing raw transaction bytes into either an Ethereum transaction
or a Cosmos transaction.
## Transactions & Messages ## Transactions & Messages
The SDK distinguishes between transactions (`sdk.Tx`) and messages (`sdk.Msg`). The SDK distinguishes between transactions (`sdk.Tx`) and messages (`sdk.Msg`).
A `sdk.Tx` is a list of `sdk.Msg`s wrapped with authentication and fee data. Users A `sdk.Tx` is a list of `sdk.Msg` wrapped with authentication and fee data. Users
can create messages containing arbitrary information by implementing the `sdk.Msg` can create messages containing arbitrary information by implementing the `sdk.Msg`
interface. interface.
@ -42,25 +28,21 @@ It addition, it implements the Cosmos SDK `sdk.Msg` interface for the sole purpo
of being to perform basic validation checks in the `BaseApp`. It, however, has of being to perform basic validation checks in the `BaseApp`. It, however, has
no distinction between transactions and messages. no distinction between transactions and messages.
The `EmbeddedTx`, being analogous to the Cosmos SDK `sdk.StdTx`, implements the
Cosmos SDK `sdk.Tx` interface.
## Signatures ## Signatures
Ethermint supports [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md) Ethermint supports [EIP-155](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-155.md)
signatures. A `Transaction` is expected to have a single signature for Ethereum signatures. A `Transaction` is expected to have a single signature for Ethereum
routed transactions. However, just as in Cosmos, Ethermint will support multiple routed transactions. However, just as in Cosmos, Ethermint will support multiple
signers for `EmbeddedTx` Cosmos routed transactions. Signatures over the signers for `auth.StdTx` Cosmos routed transactions. Signatures over the
`Transaction` type are identical to Ethereum. However, the `EmbeddedTx` contains `Transaction` type are identical to Ethereum. However, the `auth.StdTx` contains
a canonical signature structure that contains the signature itself and other a canonical signature structure that contains the signature itself and other
information such as an account's sequence number. The sequence number is expected information such as an account's sequence number. This, in addition to the chainID,
to increment every time a message is signed by a given account. This, in addition helps prevent "replay attacks", where the same message could be executed over and
to the chain ID, prevents "replay attacks", where the same message could be over again.
executed over and over again.
An `EmbeddedTx` list of signatures must much the unique list of addresses returned An `auth.StdTx` list of signatures must much the unique list of addresses returned
by each message's `GetSigners` call. In addition, the address of first signer of by each message's `GetSigners` call. In addition, the address of first signer of
the `EmbeddedTx` is responsible for paying the fees. the `auth.StdTx` is responsible for paying the fees.
## Gas & Fees ## Gas & Fees