SIP-91: Debt Cache Contract

SIP-91 proposes splitting debt snapshot logic out of the Issuer and into its own contract.

This will create a new smart contract, allowing the Issuer’s code to be small enough to fit on L2.

i realize this is just a one-off, but curious whether you anticipate the mainnet and L2 system instances to diverge meaningfully over time?

In general the plan is to ensure that as much of the code as possible operates on both L1 and L2 without modification. Of course there are limitations and advantages to each layer: we’re able to turn off the snapshotting mechanism on L2 because the OVM is efficient enough to permit it. The point is that the contract architecture needs to be modular enough that you can drop in replacement components that just turn particular features on or off without fundamentally changing much logic (meaning we want to keep the maintenance overhead low). In some sense, although the deployed code of DebtCache and RealtimeDebtCache are substantially different, they are not meaningfully different with respect to the functionality of systems that rely on them.

It may be the case that there are operations that are just so much better (or only possible) on one layer or the other that in future those things live only on that layer. Perhaps as more projects commit to a particular layer and the composability benefits make themselves known, more capital and resources will be dedicated to one side. This might not evince itself in the shape of a hard discrepancy between code versions though. It might be the case, for example, that while futures can operate on both L1 and L2 with the same basic smart contracts, oracle updates are only frequent/cheap enough to make trading futures worthwhile on L2.

I think it might be a bit early to draw conclusions yet, as we’re still feeling the technical architecture out ourselves. Check out this recently-released blog post by Kain discussing these matters in more detail.

1 Like