Skip to content

Latest commit

 

History

History
69 lines (47 loc) · 4.95 KB

cip-0057.md

File metadata and controls

69 lines (47 loc) · 4.95 KB
Raw
cip title author discussions-to status type category created license
57
Remove full node incentives
Gastón Ponti (@gastonponti), Paul Lange (@palango)
Final
Standards Track
Ring 0
2023-06-20
Apache 2.0

Simple Summary

Remove the ability to pay gateway fees in transactions.

Abstract

This CIP proposes to consider transactions, with a gateway fee bigger than zero, invalid. The gateway fee is a mechanism that CELO transactions have to be able to pay an extra fee to a particular address, with the objective of creating an incentive for full nodes to accept transactions from light clients.

Motivation

The gateway fee mechanism was never properly executed. The conditions in the state transition to be able to pay for this transactions are completely defined and working, but all the conditions required for the light client to select the full node with better price and latency are not yet 100% defined. Today, the gateway fee mechanism is a halfway baked feature that is adding more complexity to our client in comparison to upstream with no gain at all. The rationale behind this decision in the past, was that changing the transaction format after the mainnet launch was going to be harder than having both extra fields from the beginning. This assumption changes after the implementation of the EIP-2718 (enveloped transactions), which allows us to include different new transaction types without requiring too much complexity from the client side.

In the pursue of maintaining our execution layer as close to Ethereum as possible, to be able to perform faster updates, this halfway feature just adds unnecessary complexity until it is completely defined. There’s no guarantee that the actual implementation of this feature will require these two fields, and today’s implementation only opens the door to a different set of questions:

  • In a network that relies on the transaction gossip to reach one of the actual validators, why the other full nodes that are offering the same service are going to propagate the transactions that will be paid to their competitors?
  • Could this mechanism give clues of the origin of some transactions? Could a validator used this to censor some accounts? (Let’s say that forno requires a minimum gateway fee, all the block proposers could check that the gateway fee recipient is the one for forno, and avoid its inclusion for some regulation issue)
  • Are the lightest clients supposed to be served by only one full node? What could happen if another full node connected to the same lightest client refuses their connection because the lightest user is paying only the request of the other full node? Would this generate an unhealthy clusterization in the network?

Specification

  • Validate in the applyTransaction function if the transaction has either the gatewayFee or gatewayFeeRecipient set, and fail if that is the case
  • Add the same check to the transaction pool, so that invalid transaction cannot be added there
  • Deprecate the --light.gatewayfee command line argument
  • Throw errors from the following functions and properties from the JS interface after the hardfork:
    • setGatewayFeeRecipient(...)
    • requestPeerGatewayFees(...)
    • suggestGatewayFee(...)
    • setGatewayFee(...)
    • gatewayFee
    • gatewayFeeRecipient
    • gatewayFeeCache

The removal of the gateway fee also allows further simplifications in the LES protocol. But as this protocol is versioned, the changes can be done independently of a hardfork and are therefore not specified in this CIP.

Rationale

Not only the removal of this feature will simplify the code base and reduce the divergence from upstream geth, thereby making Celo clients more maintainable but also, today’s implementation allows the user to use the gateway fee as a tool to avoid paying the actual fees that it should pay. Scenarios like making two native celo transactions at the cost of only one, or even pay for a celo native transaction but generate a stabletoken transaction without paying for its costs, are possible with the actual implementation.

The full nodes incentives are a key feature for our lightest clients, but this should be defined first, and decide if we actually need fields in our transactions, or a different approach (which are not going to be discussed in this cip)

Backwards Compatibility

This CIP will require a hard fork.

Implementation

See this PR

Security Considerations

This functionality is not used. The only scenarios where someone could be using it, are to avoid paying fees, which are not the purpose of this feature, being a bad use of it. Removing this functionality it shouldn’t break anything.

License

This work is licensed under the Apache License, Version 2.0.