status-im/EIPs
2
0
Fork 0
mirror of https://github.com/status-im/EIPs.git synced 2025-02-26 13:45:22 +00:00
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 1077

Browse Source 
Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing draft EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Alex Van de Sande 2018-05-18 10:27:27 -04:00 committed by EIP Automerge Bot
parent 9fc98f1f0f
commit 165d382593
1 changed files with 12 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
EIPS/eip-1077.md
View File

@ -51,29 +51,35 @@ All accounts that will be requesting the transaction must sign a messageHash tha
```
keccak256(
callPrefix,
byte(0x19),
byte(0),
from,
callPrefix,
to,
value,
dataHash,
nonce,
gasPrice,
gasLimit,
gasToken
gasToken,
operationType
);
```
The first and second fields are to make it [ERC191](https://eips.ethereum.org/EIPS/eip-191) compliant. Starting a transaction with byte(0x19) ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte.
The `from` field will always be the contract executing the code (`address(this)`), and the `callPrefix` is the 4 byte standard prefix of the function to be called in the `from` contract. This guarantees that a signed message can be only executed in a single instance.
`operationType` type will define what sort of operation will be executed (in assembly): 0 for a standard `call`, 1 for a `DelegateCall` and 0 for a `create` opcode. These can be extended in the future.
All signed messageHashes should then be ordered by account and sent to the receiveing contract which then will execute the following actions:
#### keep track of nonces:
If the nonce number is smaller than 10^24 then it should be treated as a Nonce:
Nonces work similarly to normal ethereum transactions: a transaction can only be executed if it matches the last nonce + 1, and once a transaction has occurred, the `lastNonce` will be updated to the current one. This prevents transactions to be executed out of order or more than once.
If it’s larger than 10^24 *and* larger than the current timestamp multiplied by 10^12 *and* larger than `lastTimestamp` then it should be executed normally but instead of updating the nonce you must update the last Timestamp field. This allows transactions to be scheduled to be executed at a later time. Notice that if multiple timestamped transactions are signed, they **must be executed in the numerical order** (with 10^24 possible transaction slots for every second), otherwise the earlier transaction will not be executable.
Contracts should accept transactions without nonce (nonce = 0). The contract then must keep the full hash of the transaction to prevent it from being replayed. This option allows contracts to have more flexibilities as you can sign a transaction that can be executed out of order or not at all, but it uses more memory for each transaction. It can be used, for instance, for transactions that the user wants to schedule in the future but cannot know its future nonce, or transactions that are made for state channel contracts that are not guaranteed to be executed or are only executed when there's some dispute.
### execute transaction
@ -109,6 +115,7 @@ executeSigned(
uint gasPrice,
uint gasLimit,
address gasToken,
operationType
bytes messageSignatures)
`
@ -126,6 +133,7 @@ gasEstimate(
uint gasPrice,
uint gasLimit,
address gasToken,
operationType
bytes messageSignatures)
returns (
bool canExecute,