contract design - one time use or immortal?

mjm

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:

1. 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.
   
2. 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?

o0ragman0o

I tend much more to the OTU model. A transaction between parties should be as encaptulated as possible leaving only the minimum necessary impact on the block chain. The expenses incurred by the parties are no one else's business so it makes no sense to distribute that cost into a common.

Another thought may be to use an immortal contract without storage and have it launch whisper messages for the escrow function, perhaps having the message hold a n of m key or such.

Just thoughts. Still very early in learning this platform.

Jasper

So far i have made them immortal.(though i have put in a suicide option) Contracts often have a permanent owner, and otherwise everything is deleted if none of the other parties have any interests in it anymore.

nejucomo

In terms of auditability of one-time contracts, so long as it's easy/convenient to check the code hash of contracts, this shouldn't be too burdensome.

For this reason, one-time-use contracts should be designed with configurable parameters outside of the code. For example, imagine a standard escrow contract that requires an escrow deposit which is an agreed upon fraction of a fulfilling payment. Different parties may want different fractions, eg: 0.1, 10.0, etc...

If the code defines this as a constant, then every one-time use of this code will have a different code hash. If instead, the code has a "constructor phase" which takes the fraction as a parameter, then all such one-time contracts will have the same code hash. In that latter case, parties to an agreement can do a simple sanity check: "Is this that one escrow contract I know and love? Yep. Ok, what's the fraction parameter set to?"

I haven't gotten up to speed on solidity yet, but I hope it will codify this pattern of construction with one-time setup parameters separated from the code.

nejucomo

By examining the output of serpent compile_to_lll on some test cases, it appears as if the contract initialization code might be able to use message data to initialize parameters, which may preserve a stable code hash with different setup parameters. Maybe I should post a separate question about this pattern.