I've been thinking about how to design an Ethereum contract that might be used many times but whose individual uses have a finite duration. An example would be an escrow contract between a buyer and seller. The two main alternatives are:
- One time use. The contract lifecycle matches the interaction between the parties in a single instance of the contract. For example, an escrow contract would be created at the start of an escrow period and would suicide() as soon as the escrow was settled. The contract storage would contain data only for this one particular escrow and its logic would have no provisions for tracking multiple escrow agreements.
- Immortal. The contract is created once and remains active in the blockchain indefinitely. Any number of unrelated uses of the contract may occur simultaneously. The contract maintains state for each of these uses with structured storage. Its logic understands who is using the contract and how to work with an individual instance in structured storage.
Some of the trade-offs:
- The one-time contract incurs its creation cost on each use, while the immortal contract incurs this cost just once.
- The one-time contract incurs storage cost of sharable data on each user, while the immortal contract amortizes the shared data cost across all users.
- The one-time contract has simpler logic and storage structure.
- The one-time contract naturally cleans up after itself at the end of each use, while the immortal contract needs to do work to clear storage that is no longer required.
- The one-time logic may be updated the next time it is used just by using updated contract code, while the immortal contract must be created anew or use one of the usual techniques for mutable logic (say, indirection to dispatch to replaceable sub-contracts).
- The one-time contract may be harder to audit since a new instance is created on-demand, while the immortal contract sits in the blockchain for all to see and review.
The one-time contract has the feel of an object instance in an object-oriented programming language. The immortal contract feels more like plain old C. My instinct is to prefer the one-time design, but this seems to go against the grain of most of the examples given by the Ethereum developer team.
Any thoughts on how to think about this design question?