-
Notifications
You must be signed in to change notification settings - Fork 21
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
Signed, timestamped receipt of fulfillment #149
Comments
Sounds good. I'm not sure if server push is necessary though; don't we want the ledger to be as passive as possible? |
Instead of HTTP/2 push it could use the existing notification architecture. |
Isn't this already the case? When a ledger receives a fulfillment, it first validates that it fulfills a condition (execution or cancellation) on the specified transfer, then validates that the transfer is in an appropriate state for the fulfillment (you can't reject an executed transfer, or execute an expired transfer), then executes/rejects and returns a success code. If the client gets a success from the fulfillment endpoint, they should trust that the transfer has been updated. Can you clarify why this is necessary? |
Let's say a ledger has two transfers that depend on the same condition, but they have different expiry times. I'm the connector that needs to get paid back by the transfer that expires earlier. I submit the fulfillment to the ledger after my transfer's expiry date but before that of the other one, it executes the transfer that's not already expired, doesn't do anything with mine because it's already expired, and returns an |
OK, in light of that use case, this makes perfect sense. Is this change required for atomic mode? |
In atomic mode there are (probably) no timeouts on the transfers, so this feature isn't as needed on the ledger. However, the notary should behave in the same manner described for the ledger here. If the recipient needs to submit the receipt to the notary or notaries before a specific expiry time, they will also want proof that they submitted it in time. Arguably, we should think of this as a general behavior for any system using crypto conditions and fulfillments. A common behavior will be requiring that a condition is fulfilled before some time. In order for the submitter to be assured that they've met the condition in time they'll want a signed, timestamped acknowledgement of receipt. |
Can you explain the reasoning for this? |
Both ledgers and notaries are systems that respond to cryptographic conditions/fulfillments and enforce timeouts. @justmoon could probably explain this better than I but the general idea is that a lot more systems than just ledgers and notaries could be set up to communicate and coordinate actions between them using this primitive of the cryptographic conditions and fulfillments. This would enable atomic or semi-atomic actions to take place across widely disparate systems (e.g. a shipping company delivers physical goods, some banks execute some payments, digital titles are transferred, all based on the cryptographic "green light" given by a smart contract enforcing some multi-sig agreement between different people). In order for this more general principle to apply we'll need to move further away from the coupling of transfers and crypto conditions. The main change to the ledger to make that happen would be to give crypto conditions deterministic IDs (@justmoon is already working on this), make a generic endpoint for posting fulfillments for any type of condition, and make the ledger look up the things that must be triggered by the incoming fulfillment and act accordingly. |
So would the request still contain some kind of reference to the list of conditions that it is supposed to fulfill? It seems important to avoid checking every condition in the ledger for each fulfillment. |
No, but that should be easy to address with a database index |
I don't follow, how would a database index help here? |
Suppose a transfer has the condition Having a fulfillment means you can 1) verify that the fulfillment is valid and 2) generate the condition that it is fulfilling. So the ledger does 1) and if the fulfillment is valid it does 2) and gets back So all it needs for that flow is an index that maps conditions -> transfers. |
Ah, I didn't realize that you could generate the condition from the fulfillment, I think I get it now. I still have many questions on this topic in general. I'm not sure how developed this proposal is, but it would be helpful to see a design rationale document at some point so that we could understand better the use cases and design goals. |
When the ledger receives a fulfillment, the entity submitting it will want to know whether the event they were trying to trigger happened (e.g. the connector in Universal mode wants to know the source transfers were executed). There are two ways of achieving this:
@justmoon and I discussed this and agreed that the second option is the better, more general solution to the problem. If the submitter of a condition fulfillment gets a signed, timestamped receipt they can check that that the timestamp is before the expiry of whatever they wanted to trigger and be sure that the receiving system should trigger that event.
This means that the ledger must ensure that if it says that a fulfillment was received before the expiry time of a transfer that it fulfills, that transfer will be executed (even if the ledger only gets to processing the transfer / marking it as executed after the expiry time).
In the case of the connector in Universal mode submitting the fulfillments to the source transfers, the basic behavior is that the connector will check for the HTTP 200 status code and timestamp on the fulfillment it gets back from the ledger to make sure it is before the transfer's
expires_at
time. This gives the connector proof that the transfer will be executed.If the connector wants an explicit acknowledgement that the specific transfer was executed, they can request the transfer resource from the ledger. To improve the performance of this, the ledger can use HTTP/2 Server Push to push the transfer resource to the connector after the transfer is processed and (potentially) before the connector requests it.
The text was updated successfully, but these errors were encountered: