You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Issues can arise due to bugs within the EOS EVM Contract that causes it to deviate from the intended behavior of the EVM protocol. This can lead to the state in the contract deviating from what it should be (and also deviating from what it is in the EOS EVM Node).
These deviations are possible without the EOS EVM Node necessarily failing to replay the virtual blockchain constructed from the transactions processed by EOS EVM Contract and committed within the EOS blockchain. In such a case, the easiest path to correcting the deviation is to simply correct to state to what it should be.
So, this issue tracks an enhancement to EOS EVM Contract which adds a set of new administrative actions (only callable by the same authority that can already update the EOS EVM Contract code) to modify the state in particular ways.
Three new actions are needed to modify the subset of contract state which impacts EVM state (i.e. is also replicated in EOS EVM Node):
setkvstore: Set (upsert) or remove key-value storage slots from a specified account's storage. The account should be specified by its implementation-specific account ID.
rmaccount: Remove an account (referenced by its implementation-specific account ID) and add it to the gcstore table so that later garbage collection processing can clean up any storage slots it leaves behind. Note: reference counts of any code attached to the account must be updated, and if the reference count reaches zero, the code should also be removed from the tables.
addevmbal: Add a positive or negative delta to the balance stored in an EVM account. The account should be specified by its implementation-specific account ID. The invariant that the inevm table tracks the total sum of all EVM account balances should continue to be maintained (under the assumption that that the invariant was already true prior to the addevmbal action call).
Furthermore, three additional actions are needed to modify other parts of the contract state:
addopenbal: Add a positive or negative delta to the balance stored within the EOS EVM Contract on the EOS side associated with an EOS account that opened a balance in the contract. The account should be specified using the EOS account name.
rmgcstore: Remove an entry from the gcstore table. The entry should be specified by the primary key ID of the table row to be removed.
freezeaccnt: Modify a flag associated with an EVM account (specified by the implementation-specific account ID) to put it into or take it out of a freeze state. When an EVM account is in the freeze state, no interactions with it are possible. The user cannot sign a transaction for that account. A contract at that account cannot be called. It should not even be possible to send value to the frozen account.
The text was updated successfully, but these errors were encountered:
Issues can arise due to bugs within the EOS EVM Contract that causes it to deviate from the intended behavior of the EVM protocol. This can lead to the state in the contract deviating from what it should be (and also deviating from what it is in the EOS EVM Node).
These deviations are possible without the EOS EVM Node necessarily failing to replay the virtual blockchain constructed from the transactions processed by EOS EVM Contract and committed within the EOS blockchain. In such a case, the easiest path to correcting the deviation is to simply correct to state to what it should be.
So, this issue tracks an enhancement to EOS EVM Contract which adds a set of new administrative actions (only callable by the same authority that can already update the EOS EVM Contract code) to modify the state in particular ways.
Three new actions are needed to modify the subset of contract state which impacts EVM state (i.e. is also replicated in EOS EVM Node):
setkvstore
: Set (upsert) or remove key-value storage slots from a specified account's storage. The account should be specified by its implementation-specific account ID.rmaccount
: Remove an account (referenced by its implementation-specific account ID) and add it to thegcstore
table so that later garbage collection processing can clean up any storage slots it leaves behind. Note: reference counts of any code attached to the account must be updated, and if the reference count reaches zero, the code should also be removed from the tables.addevmbal
: Add a positive or negative delta to the balance stored in an EVM account. The account should be specified by its implementation-specific account ID. The invariant that theinevm
table tracks the total sum of all EVM account balances should continue to be maintained (under the assumption that that the invariant was already true prior to theaddevmbal
action call).Furthermore, three additional actions are needed to modify other parts of the contract state:
addopenbal
: Add a positive or negative delta to the balance stored within the EOS EVM Contract on the EOS side associated with an EOS account that opened a balance in the contract. The account should be specified using the EOS account name.rmgcstore
: Remove an entry from thegcstore
table. The entry should be specified by the primary key ID of the table row to be removed.freezeaccnt
: Modify a flag associated with an EVM account (specified by the implementation-specific account ID) to put it into or take it out of a freeze state. When an EVM account is in the freeze state, no interactions with it are possible. The user cannot sign a transaction for that account. A contract at that account cannot be called. It should not even be possible to send value to the frozen account.The text was updated successfully, but these errors were encountered: