Jonathan Jove <
j...@stellar.org> writes:
> I think the question "what happens when a reactivated ledger entry already
> exists" is the single most important detail here, and warrants significant
> further discussion.
>
> In general, per-ledger-entry-type merge semantics will not be possible in
> the context of smart contracts. How could the system possibly know what the
> smart contract wants to happen, unless the smart contract itself specifies
> the semantics it wants? Doing this seems like a lot of extra work for
> contract developers and is unlikely to be popular.
Mostly this comes down to how we identify ledger entries. If, for
instance, ledger entries have some identifier that is unique over all
time, then there is no issue.
That said, if we solve the identity problem and ledger entry identities
are not unique over all time, I still don't see why it needs to be a
huge amount of work for smart contract authors. We could have the
default be that you can't resurrect something if the ID is in use. And
we could have an option where if the ledger entry is associated with a
smart contract and the smart contract wants, it can do something simple
like sum a field in the two versions. I think "disallow resurrection"
and "merge by summing balances" would probably cover 95+% of cases.
Also note that disallowing resurrection doesn't mean the funds are
lost. It just means you need to withdraw, merge, or otherwise destroy
the current entry so as to resurrect a previous one.
> I suspect there are significant vulnerabilities associated with forbidding
> reactivation if a collision would occur. For example, consider the case
> where a long-term escrow contract is archived. If an attacker can create a
> contract at that address, then they could create a do-nothing contract
> preventing the real contract from being reactivated. This would permanently
> lock the funds in the escrow.
I think abstractly this sounds like a problem. But in a concrete
setting, it may be that people sign half of escrow transactions that
never get submitted, so we need a mechanism for making sure transactions
on old escrow accounts can't be applied out of context to new escrow
accounts. So big picture, you might want to give escrow accounts a
unique identity over all time anyway, and that would solve the
resurrection problem.
Of course, it may be possible to construct contrived smart contracts
that are vulnerable to this kind of issue and to nothing else. So I
think the question has to be answered with a concrete example. We have
to look at the vulnerable contract and the correct one, and if the
correct contract is more complicated to write, then we have a problem.
But if the vulnerable contract is complex and contrived compared to the
correct contract which is the obvious way of doing things, then this
doesn't worry me too much.
David