Skip to content

Commit

Permalink
Merge branch 'master' into AI
Browse files Browse the repository at this point in the history
  • Loading branch information
jamesavechives authored Feb 13, 2025
2 parents 9c4859f + bc49139 commit 9be478c
Show file tree
Hide file tree
Showing 3 changed files with 37 additions and 33 deletions.
26 changes: 15 additions & 11 deletions ERCS/erc-7573.md
Original file line number Diff line number Diff line change
Expand Up @@ -30,7 +30,7 @@ Within the domain of financial transactions and distributed ledger technology (D
The concept may help to solve the challenge of delivery-versus-payment (DvP), especially in cases where the asset chain and payment system (which may be a chain, too) are separated.
A prominent application of smart contracts realizing a secure DvP is that of buying an asset, where the asset is managed on one chain (the asset chain), but the payments are executed on another chain (the payment chain).
Proposed solutions are based on an API-based interaction mechanism which bridges the communication between a so-called asset chain and a corresponding
payment system or requires complex and problematic time-locks.[^1]
payment system or requires complex and problematic time locks.[^1]

Here, we propose a protocol that facilitates secure delivery-versus-payment with less overhead, especially with a stateless oracle.[^2]

Expand All @@ -52,7 +52,7 @@ function inceptTransfer(bytes32 id, int amount, address from, string memory keyE

Called from the buyer of the token to initiate token transfer. Emits a `TransferIncepted` event.
The parameter `id` is an identifier of the trade. The parameter `from` is the address of the seller (the address of the buyer is `msg.sender`).
The parameter `keyEncryptedSeller` is an encryption of the key that can be used by the seller to (re-)claim the token. See below on "encryption".
The parameter `keyEncryptedSeller` is an encryption (or, alternatively, hash) of the key that can be used by the seller to (re-)claim the token. See below on "encryption".

##### Initiation of Transfer: `confirmTransfer`

Expand All @@ -62,7 +62,7 @@ function confirmTransfer(bytes32 id, int amount, address to, string memory keyEn

Called from the seller of the token to confirm token transfer. Emits a `TransferConfirmed` event.
The parameter `id` is an identifier of the trade. The parameter `to` is the address of the buyer (the address of the seller is `msg.sender`).
The parameter `keyEncryptedBuyer` is an encryption of the key that can be used by the buyer to claim the token.
The parameter `keyEncryptedBuyer` is an encryption (or, alternatively, hash) of the key that can be used by the buyer to claim the token.

If the trade specification, that is, the quadruppel (`id`, `amount`, `from`, `to`), in a call to `confirmTransfer`
matches that of a previous call to `inceptTransfer`, and the balance is sufficient, the corresponding `amount`
Expand Down Expand Up @@ -126,9 +126,9 @@ function transferAndDecrypt(bytes32 id, int amount, address to, string memory ke
Called from the sender of the amount to initiate completion of the payment transfer. Emits a `TransferKeyRequested` with keys depending on completion success.
The parameter `id` is an identifier of the trade. The parameter `to` is the address of the receiver of the payment (the sender of the payment (from) is implicitly the `msg.sender`).
The parameter `keyEncryptedSuccess` is an encryption of the key and will be decrypted if the transfer is successful.
The parameter `keyEncryptedFailure` is an encryption of the key and will be decrypted if the transfer failed.
The parameter `keyEncryptedFailure` is an encryption of the key and will be decrypted if the transfer fails.

The method will not decrypt any key and not perfrom a transfer of a payment if the values (`id`, `amount`, `from` `to`, `keyEncryptedSuccess`, `keyEncryptedFailure`)
The method will not decrypt any key and not perform a transfer of a payment if the values (`id`, `amount`, `from` `to`, `keyEncryptedSuccess`, `keyEncryptedFailure`)
do not match a previous call to `inceptTransfer`.

##### Cancelation of Transfer: `cancelAndDecrypt`
Expand All @@ -141,8 +141,8 @@ Called from the receiver of the amount to cancel payment transfer (cancels the i

The method must be called from the caller of a previous call to `inceptTransfer`
with the exact same arguments and cancels this specific transfer.
If these preconditions are meet and a valid call to `transferAndDecrypt` has not been issued before,
i.e. if `keyEncryptedSuccess` has not been dissued in a `TransferKeyRequested` event,
If these preconditions are met and a valid call to `transferAndDecrypt` has not been issued before,
i.e. if `keyEncryptedSuccess` has not been issued in a `TransferKeyRequested` event,
then this method emits a `TransferKeyRequested` with the key `keyEncryptedFailure`.

##### Release of ILockingContract Access Key: `releaseKey`
Expand Down Expand Up @@ -185,6 +185,11 @@ It is implicitly assumed that the two parties may check that
the strings `keyEncryptedBuyer` and `keyEncryptedSeller` are
in a valid format.

To avoid on-chain encryption in the `ILockingContract`, it is possible to use a simpler hashing algorithm
on the `ILockingContract`. In that case, the decryption oracle has
to provide a method that allows to obtain the hash *H(K)* for an
encrypted key *E(K)* without exposing the key *K*, cf. [^2].

### Sequence diagram of delivery versus payment

The interplay of the two smart contracts is summarized
Expand All @@ -195,7 +200,7 @@ in the following sequence diagram:
## Rationale

The protocol tries to be parsimonious. The transfer
is associated with a (preferable unique) `id` possibly
is associated with a (preferably unique) `id` possibly
generated by some additional interaction of the trading
parties.

Expand All @@ -213,7 +218,7 @@ It seems as if this would require us to introduce a concept of eligibility to th
A fully stateless decryption can be realized by introducing a document format for the key and a corresponding eligibility verification protocol. We propose the following elements:

- The (unencrypted) key documents contain the address of the payment contract implementing `IDecryptionContract`.
- The decryption oracle offers a stateless function `verify` that that receives an encrypted key and returns the callback address (that will be used for the `releaseKey` call) that is stored inside the decrypted key without returning the decrypted key.
- The decryption oracle offers a stateless function `verify` that receives an encrypted key and returns the callback address (that will be used for the `releaseKey` call) that is stored inside the decrypted key without returning the decrypted key.
- When an encrypted key is presented to the decryption oracle, the oracle decrypts the document and passes the decrypted key to `releaseKey` of the callback contract address found within the document decrypted key.

We propose the following XML schema for the document of the decrypted key:
Expand All @@ -232,7 +237,7 @@ We propose the following XML schema for the document of the decrypted key:
</xs:schema>
```

A corresponding sample XML shown below.
A corresponding sample XML is shown below.
```xml
<root xmlns:ilc="http://finnmath.net/erc/ILockingContract">
<ilc:releaseKey contract="eea9e1da-d56a-4c0a-9c08-f2e76f616426">
Expand Down Expand Up @@ -340,4 +345,3 @@ Copyright and related rights waived via [CC0](../LICENSE.md).
"URL": "http://dx.doi.org/10.2139/ssrn.4628811"
}
```

14 changes: 7 additions & 7 deletions assets/erc-7573/contracts/IDecryptionContract.sol
Original file line number Diff line number Diff line change
Expand Up @@ -7,23 +7,23 @@ pragma solidity >=0.7.0;
* @title ERC-7573 Decryption Contract - Conditional decryption of keys, conditional to transfer success.
* @dev Interface specification for a smart contract that enables secure stateless delivery-versus-payment.
*
* The specification consists of two interface,
* The specification consists of two interfaces,
* one is implemented by a smart contract on one chain (e.g. the "asset chain" - the asset contract), the other is implemented by
* a smart contract on another chain (e.g. the "payment chain" - the payment contract).
* One contract performs a locking, where a transfer is conditional on a presented key: locking contract.
* The other contract performs a condition decryption of keys, conditional to transfer success of failure: decryption contract.
* The other contract performs a condition decryption of keys, conditional to transfer success or failure: decryption contract.
*
* This is the decryption contracts interface.
*
* The rationale is that a transfer in setup with two encrypted keys, the encryptedSuccessKey and the encryptedFailureKey.
* Upon transfer a conditional decryption of one the encrypted keys is performed.
* The rationale is that a transfer is set up with two encrypted keys, the encryptedSuccessKey and the encryptedFailureKey.
* Upon transfer, a conditional decryption of one of the encrypted keys is performed.
*/
interface IDecryptionContract {

/*------------------------------------------- EVENTS ---------------------------------------------------------------------------------------*/

/**
* @dev Emitted when the transfer is incepted.
* @dev Emitted when the transfer is incepted.
* @param id the trade identifier of the trade.
* @param amount the amount to be transferred.
* @param from The address of the sender of the payment.
Expand All @@ -34,7 +34,7 @@ interface IDecryptionContract {
event TransferIncepted(bytes32 id, int amount, address from, address to, string keyEncryptedSuccess, string keyEncryptedFailure);

/**
* @dev Emitted when a the transfer has been performed with a success or failure.
* @dev Emitted when a transfer has been performed with a success or failure.
* @param id the trade ID.
* @param encryptedKey The encrypted key associated with the transaction status.
*/
Expand Down Expand Up @@ -89,4 +89,4 @@ interface IDecryptionContract {
* @param key Decrypted key.
*/
function releaseKey(bytes32 id, string memory key) external;
}
}
30 changes: 15 additions & 15 deletions assets/erc-7573/contracts/ILockingContract.sol
Original file line number Diff line number Diff line change
Expand Up @@ -4,21 +4,21 @@ pragma solidity >=0.7.0;
/*------------------------------------------- DESCRIPTION ---------------------------------------------------------------------------------------*/

/**
* @title ERC-7573 Locking Contract - Conditional unlocking of tokens, conditional to presentation of key.
* @title ERC-7573 Locking Contract - Conditional unlocking of tokens, conditional to the presentation of a key.
* @dev Interface specification for a smart contract that enables secure stateless delivery-versus-payment.
*
* The specification consists of two interface,
* The specification consists of two interfaces,
* one is implemented by a smart contract on one chain (e.g. the "asset chain" - the asset contract), the other is implemented by
* a smart contract on another chain (e.g. the "payment chain" - the payment contract).
* One contract performs a locking, where a transfer is conditional on a presented key: locking contract.
* The other contract performs a condition decryption of keys, conditional to transfer success of failure: decryption contract.
* The other contract performs a condition decryption of keys, conditional to transfer success or failure: decryption contract.
*
* This is the locking contracts interface.
*
* The rationale is that the token is locked with with two encrypted keys
* or a hashes of keys associated with two different adresses (buyer/seller).
* The rationale is that the token is locked with two encrypted keys
* or hashes of keys associated with two different adresses (buyer/seller).
*
* The asset in transfered to the address of the buyer, if the buyer's key is presented.
* The asset is transfered to the address of the buyer, if the buyer's key is presented.
*
* The asset in (re-)transfered to the address of the seller, if the seller's key is presented.
*/
Expand All @@ -31,7 +31,7 @@ interface ILockingContract {
* @param id the trade identifier of the trade.
* @param from The address of the seller.
* @param to The address of the buyer.
* @param keyEncryptedSeller Encryption of the key that can be used by the seller to (re-)claim the token.
* @param keyEncryptedSeller Encryption (or, alternatively, hash) of the key that can be used by the seller to (re-)claim the token.
*/
event TransferIncepted(bytes32 id, int amount, address from, address to, string keyEncryptedSeller);

Expand All @@ -41,12 +41,12 @@ interface ILockingContract {
* @param amount the number of tokens to be transfered.
* @param from The address of the seller.
* @param to The address of the buyer.
* @param keyEncryptedBuyer Encryption of the key that can be used by the buyer to claim the token.
* @param keyEncryptedBuyer Encryption (or, alternatively, hash) of the key that can be used by the buyer to claim the token.
*/
event TransferConfirmed(bytes32 id, int amount, address from, address to, string keyEncryptedBuyer);

/**
* @dev Emitted when the token was successfully claimed (forward to buyer).
* @dev Emitted when the token was successfully claimed (forwarded to the buyer).
* @param id the trade ID
* @param key the key that was used to claim the asset
*/
Expand All @@ -62,30 +62,30 @@ interface ILockingContract {
/*------------------------------------------- FUNCTIONALITY ---------------------------------------------------------------------------------------*/

/**
* @notice Called from the buyer of the token to initiate token transfer.
* @notice Called from the buyer of the token to initiate the token transfer.
* @dev emits a {TransferIncepted}
* @param id the trade identifier of the trade.
* @param amount the number of tokens to be transfered.
* @param from The address of the seller (the address of the buyer is message.sender).
* @param keyEncryptedSeller Encryption of the key that can be used by the seller to (re-)claim the token.
* @param keyEncryptedSeller Encryption (or, alternatively, hash) of the key that can be used by the seller to (re-)claim the token.
*/
function inceptTransfer(bytes32 id, int amount, address from, string memory keyEncryptedSeller) external;

/**
* @notice Called from the seller of the token to confirm token transfer. Locks the token.
* @notice Called from the seller of the token to confirm the token transfer. Locks the token.
* @dev emits a {TransferConfirmed}
* @param id the trade identifier of the trade.
* @param amount the number of tokens to be transfered.
* @param to The address of the buyer (the address of the seller is message.sender).
* @param keyEncryptedBuyer Encryption of the key that can be used by the buyer to claim the token.
* @param keyEncryptedBuyer Encryption (or, alternatively, hash) of the key that can be used by the buyer to claim the token.
*/
function confirmTransfer(bytes32 id, int amount, address to, string memory keyEncryptedBuyer) external;

/**
* @notice Called from the buyer or seller to claim or (re-)claim the token. Unlocks the token.
* @dev emits a {TokenClaimed} or {TokenReclaimed}
* @param id the trade identifier of the trade.
* @param key The key for which the hash or encryption matches either keyEncryptedBuyer (for transfer to buyer) or keyEncryptedSeller (for transfer to seller).
* @param key The key for which the hash or encryption matches either keyEncryptedBuyer (for transfer to the buyer) or keyEncryptedSeller (for transfer to the seller).
*/
function transferWithKey(bytes32 id, string memory key) external;
}
}

0 comments on commit 9be478c

Please sign in to comment.