In the case of Arbitrum at least, there’s a global Address Registry that you would probably want to use instead of a local account mapping since that would remove the redundant one-time cost of registering the address (since the address in question would likely have already been registered in the global Address Registry, and if not, is likely to be registered there at some later point anyway).
Dunno, gotta look at how that works. I had a feeling something like that existed.
In the case of Stake Curate (the WIP implementation of the List Prebuilt) needs the Account abstraction to take note of balances. That balance will have to be stored internally in some struct anyway. And there’s spare space in a 256 bit slot, it just happens to be enough for an address.
I’d have to research if there’s any potential benefit in having the “rollup native” Address Registry map to this struct internally, instead of keeping custom accountIds. But it may be more trouble than it’s worth and it’d tie the Prebuilt to a particular rollup.
Also, doing so would eliminate the possibility to keep separate accounts (with their balances) by the same address, which can be useful (for example, you can mitigate risks by submitting riskier groups of items, overcollateralized, under some account, and then use another account for others.)
As for the other Prebuilts, it may work. No serious work has been done on any of them, so I haven’t figured out if there’s any extra benefit to having inbuilt Accounts with things like balances.
having a contract address dedicated to some project (rather than a (contract, ID) pair) feels much cleaner IMO.
Prebuilts aren’t intended to be flexible, they just work with limitations. Having them super cheap is a feature. Also, having everything in the same contract enforces immutability to the events, data structure, etc, and so it allows for a subgraph, common library and stock frontend to be usable as a default browsing tool, + no need to any the extra steps in the left side of the comparison table.
The Primitive, however, should use this type of proxy contracts, to allow flexibility and being customizable with a small set of limitations.
this is a one-time operation
I don’t make that assumption, because some use cases could work with lists of lists with single items, to allow to have custom parameters per item. (Because, a List enforces a lot of settings to all items under it). I don’t want them to have extra lineal costs.
Even if these Prebuilts aren’t intended to be flexible, they still have some leeway to play with the data structure and use it in unintended ways.