Skip to content

Latest commit

 

History

History
90 lines (60 loc) · 9.39 KB

cip-16.md

File metadata and controls

90 lines (60 loc) · 9.39 KB
CIP No. Title Author Discussions Status Type Created Required CIPs
16
Consolidate Contract Destruction Logic
Chenxing Li (@ChenxingLi)
Final
Spec Breaking
2020-08-05
12

Simple Summary

Put all the logic related to contract destruction to the post-processing of transaction execution. This includes recycling storage entries, refunding sponsor balance, etc.

Abstract

Conflux introduces a sponsorship mechanism and a collateral mechanism to the Ethereum Virtual Machine. However, during contract destruction, the information for the new mechanisms is maintained at several different places. This brings a lot of issues to be solved. This proposal plans to move all the destruction-related logic to the post-processing of transaction execution. This includes removing storage entries, refunding collateral, refunding sponsor balance, etc.

Motivation

Conflux introduces a sponsorship mechanism and a collateral mechanism to the Ethereum Virtual Machine. However, these changes bring some issues in the current implementation.

  • First, the collateral for code may be refunded multiple times because a contract can be destructed multiple times in the same contract. An attacker can steal collateral using this bug.

  • Second, the recycling of storage entries (removing storage entries from state and refunding collateral) is executed per epoch. If a contract is destructed and another contract is created at the same address within the same epoch, it may falsely read the obsolete storage entries, the staking vote list and the deposit list.

  • Third, we require that the contract to be destructed has no storage collateral when it is killed by the SUICIDE (0xff) operation or by the destroy() internal contract function. (We call SUICIDE (0xff) and destroy() killing commands in the rest of this document.) But in case the killed contract acts as the storage owner via the sponsorship mechanism, it may become the storage owner of newly occupied storage after destruction.

In Ethereum, the killing command only transfers the remaining balance to a specified address and marks such contracts in the substate as "to be killed". Before the end of transaction execution, the contract to be killed act as a normal contract. But when Conflux implements the sponsor mechanism, we falsely think the contract is dead after killing operations and refund the sponsor balance and storage collateral when executing the killing command. This implementation brings a lot of corner cases to be handled and we must continue to propose CIPs (2, 8, 12) to fix them.

Since Ethereum kills all the contracts (removing their code from the word-state) at the end of transaction execution, it is a good idea to move all the logic related to killing contracts to this place. This includes moving storage recycling and collateral and sponsor balance refunds to the same place where we remove code. And thus, the collateral mechanism doesn't need to deal with the killing command as a special case.

Since Conflux does not trigger an exception in the SUICIDE (0xff) operation due to collateral, it will also not trigger an exception in the SUICIDE (0xff) operation due to invalid refund address. So the SUICIDE (0xff) operation will not generate any exceptions for now. Instead, in case a contract's balance is refunded to an invalid address, the balance of the killed contract will be burnt.

Specification

Post-processing of transaction execution

Currently, after virtual machine execution, the transaction is post-processed as follows:

  1. If the virtual machine execution succeeds, settle the storage collateral for all the storage changes during the contract execution. If the storage owner can not afford the collateral or the storage limit is not satisfied, an exception will be triggered and the state will be reverted to the version before the virtual machine execution.
  2. Refund the unused gas fee. (At most a quarter of gas limit.)
  3. Obtain the killed addresses during transaction execution from substate and remove their basic components (defined in the Conflux protocol specification) and code from the world state. Notice that in case the world state is reverted due to some exceptions, the killed addresses set in the substate must be empty.

This CIP will replace the third step with following steps,

  1. Delete all the storage entries and code of killed contracts, and refund all the related collateral to their owner. Even if a contract is killed during the execution of this transaction, it can still receive collateral refunding.
  2. Send the remaining sponsor balance of killed contracts to the corresponding sponsors. Even if a contract is killed during the execution of this transaction, it can still receive refunded sponsor balance.
  3. Send the remaining balance of killed contracts to the refunding address in their last killing command. In case the refunding address is also in killed in the same transaction, the balance to be refunded will be burnt.

Other changes

  1. For a killing command, Conflux does exactly the same thing as Ethereum.
  2. Conflux no longer recycles storage at the end of epochs since they are recycled during transaction execution.
  3. In case a contract's balance is refunded to an invalid address, SUICIDE (0xff) will not trigger an exception. The balance of such contracts will be burnt.

Rationale

The motivation part introduces the rationale for high level idea. Here we introduce the rationale for some details.

No exception in storage recycling

Storage recycling is a costly step. If an exception happens (like a NotEnoughBalanceForCollateral exception) during or after recycling, the world-state will be reverted and the storage recycling becomes useless. This may open an attack vector. So we do not put collateral settlement together with contract destruction.

Backwards Compatibility

This CIP is not backwards compatible. It will be activated at the third phase of mainnet.

Test Cases

TBA.

Implementation

TBA.

Security Considerations

This CIP resolves the bug that the code collateral can be refunded multiple times. It also considers a security issue when an exception happens during or after storage recycling.

Copyright

Copyright and related rights waived via CC0.