search

consensus-shipyard / ipc

🌳 Spawn multi-level trees of customized, scalable, EVM-compatible networks with IPC. L2++ powered by FVM, Wasm, libp2p, IPFS/IPLD, and CometBFT.
https://ipc.space
Apache License 2.0
44 stars 39 forks source link

Burn reconciliation #1081

Open raulk opened 4 months ago

raulk commented 4 months ago

Context

Subnets that use non-zero base fees forward their burns to address f099 ("burnt funds" actor inherited from Filecoin). If validators behave correctly, these funds are terminally out of circulation. However, the circulating supply accounting maintained at the parent has no knowledge of such burns.

Discussion

On the one hand, today's behaviour is technically correct, since from the perspective of the parent, these funds continue to be managed by the subnet, and the fact that they're sitting in an untouchable address is merely circumstantial.

However, taking a broader perspective, it's highly desirable for local burns to propagate up the hierarchy and be reconciled at the original supply source. This enables sounder tokenomics models and centralises supervision/introspection (e.g. it becomes possible to adjust a minting rate based on the actual circulating supply).

Potential solution

  1. Make checkpoints carry accumulated burns up the hierarchy, and reset the balance of f099 every time this happens.
  2. When processing a checkpoint at the parent, ensure it's within bounds of the perceived circulating supply of the child.
  3. If the local supply source is native, deposit the propagated burn to f099. If it's ERC20, call its burn function.

Notes

This should be fairly straightforward to implement, and some part of this is already needed for #925.

raulk commented 3 months ago

Note

When withdrawing funds from a subnet, IPC sends these funds to the local burnt funds actor, and deducts them from the circ supply of the child and the parent.

https://github.com/consensus-shipyard/ipc/blob/2bd8ef5b649d2d0b34a6e13ac52a650c973ebafa/contracts/contracts/gateway/GatewayManagerFacet.sol#L213

https://github.com/consensus-shipyard/ipc/blob/2bd8ef5b649d2d0b34a6e13ac52a650c973ebafa/contracts/contracts/gateway/router/CheckpointingFacet.sol#L137

https://github.com/consensus-shipyard/ipc/blob/ed437afeb082f06bea6f5d6ebdc3da35c1c493ae/fendermint/vm/interpreter/src/fvm/checkpoint.rs#L94

cryptoAtwill commented 3 months ago

It feels like we can introduce a state parameter or something like that in the checkpoint as well. Carry extra information, maybe for finalisation or light client.