Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stop conflating initiating-participant with first-active-participant #412

Open
AlexKnauth opened this issue Nov 10, 2021 · 4 comments
Open

Comments

@AlexKnauth
Copy link
Contributor

AlexKnauth commented Nov 10, 2021

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.

@AlexKnauth
Copy link
Contributor Author

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".

@AlexKnauth
Copy link
Contributor Author

AlexKnauth commented Dec 6, 2021

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.

@AlexKnauth
Copy link
Contributor Author

AlexKnauth commented Dec 6, 2021

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?

@AlexKnauth
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant