glow
glow copied to clipboard
Stop conflating initiating-participant with first-active-participant
Related to issue #188 for 0-transaction interactions, more important for future race
construct plans where the first-active-participant may be any of the competitors in the race.
The first-transaction-optimization should only even be considered when the initiating-participant and the first-active-participant are the same.
It might be that the first-depositing-participant could be the one to create the contract on an Account model, but not on a UTXO model.
But the first-depositing-participant might not necessarily be the "initiating-participant" or the "first-active-participant".
In these events:
A-deposit/escrow
A-commit
B-deposit
------------------------------
B-reveal
------------------------------
A-reveal
There is a constraint that A-deposit/escrow
must happen before B-reveal
, and that A-commit
must happens before B-reveal
. Also B-reveal
must happen before A-reveal
.
But there is no intrinsic constraint between A-deposit/escrow
, A-commit
, and B-deposit
. And there is no barrier between B-deposit
and B-reveal
either, just a barrier between the others and B-reveal
.
An alternative version??
A-deposit/escrow B-deposit/escrow
A-commit B-commit
----------------------------------
A-reveal B-reveal
Here there is a constraint that all 4 of the events above the line must happen before both of the events below the line. In the case where A
and B
can both agree on their reveals off-chain, this can be only 2 transactions on a UTXO model. In the case where one refuses to reveal, it would require a 3rd transaction.
Question: if the program is written like this, but without explicit escrow... assuming the escrow is always inferred properly... could the various backends optimize this same program to use their respective advantages? The compilation strategy for the Account model to optimize-away the B-commit? The compilation strategy for the UTXO model to use off-chain communication to combine the reveals in the best case?
We can make the initiating participant on Ethereum the first-depositing-participant, and worry about other backends later, and worry about being flexible with order later.