@vbuterin any kind of address mapping would mean that ttl fees grow proportionately with the number of users. I see two reasons why making each user pay for ttl of a single common contract is impossible:
-
Iterating through a registry in the evm is impossible. Even in case of a (highly suboptimal) array registry, gas costs make iterating over all users (eg. to verify “tax” payments or seize assets from nonpayers) untenable.
-
Contracts are passive. An administrator is always needed to kick off any “tax collection” logic. (Per each user, separately!)
Now because of this, paying tax is entirely voluntary, or needs an offchain tax authority. This pretty much means that registry contracts always need an organizational (usually corporate) background.
Even if “registering” requires the payment of a year’s ttl on one’s own state, after a year, “register and forget” users will invariably drag the community down.
As for ERC20 contracts spinning off balances into “coins”, I don’t see how that could maintain the ERC20 interface. balanceOf(addr) would need a way to calculate coin contract addresses, or a mapping. And if we have a mapping, we’re back at square one.
About the reactivation… What if the state is larger than the block gas limit?
@danrobinson if I’m correct you’d need to try all past nonces of the address and hash them each to get all possible child contract addresses, until you find the address, or run out of nonces. Especially with a highly active parent contract, this sounds pretty expensive for an everyday (or, more, “every millisecond”) operation. Changing the contract address calculation scheme to be bidirectional, or adding parent address as a system field would probably help.
Otherwise, I like your proposals. I guess we could take this to another thread, even though making sure that this change to Ethereum won’t favor corporations using it as a database, over spontaneous, self-sovereign individual cooperation is probably too important to be strictly offtopic.