Scalable Payments with the Multi-Party Escrow and Channels

The Multi-Party Escrow smart contract (“MPE”), coupled with our atomic unidirectional payment channels, enables scalable payments in the platform by minimizing the number of on-blockchain transactions needed between clients and AI service owners. The MPE contract has two main functionalities:

● It is a simple wallet with deposit and withdraw functions.

● It is also the set of atomic unidirectional payment channels between clients and services providers.

A payment channel is a tool that enables off-chain transactions between parties without the 15 delay imposed by blockchain block formation times and without compromising the transactional security. There are several kinds of payment channels. Let us consider the simple unidirectional payment channel:

● The sender, Alice, creates an escrow contract with a given expiration date. She funds the escrow contract with the desired amount of tokens (say, 23).

● Suppose Alice wants to send 5 AGI tokens to Bob (“recipient”). Alice sends Bob a signed authorization to close the escrow channel and withdraw 5 AGI tokens from it.

● Bob checks that the authorization is correctly signed, the amount is correct, and the amount does not exceed the escrowed funds.

● Bob can close the channel at any moment by presenting a signed authorization from Alice. In this case, Bob will be sent the 5 tokens Alice authorized, and the remaining 18 tokens in escrow will go back to Alice.

● Alice can close the channel after the expiration date and take all funds back.

● Alice can extend the expiration date and add funds to the contract at any time.

In the model above, there is no way for Bob to withdraw funds without closing the channel. Otherwise, he could use Alice’s signed authorization a second time and withdraw 5 more AGI tokens.

Therefore, we added a feature that allows Bob to withdraw funds from the channel without closing it, while preventing this replay attack. We used a simple, textbook solution: a nonce. We add a nonce to the message that the sender signs, and this nonce changes each time the recipient claims the channel.

With this improvement, payment channels inside MPE have the following favorable properties:

● The channel between sender and recipient can persist indefinitely. The sender can extend the expiration time and add funds to the channel. The recipient can claim the amount signed over to him at any time.

● The system is comfortably functional even when the Binance network is overloaded with confirmation time of several hours or even more, for the following reasons:

1. Neither the sender nor recipient needs any confirmation from the blockchain. Alice can continue to add funds, and Bob can continue to claim them in the channel, with no confirmation from the blockchain. For example, after Bob claims his funds, he can inform Alice that the nonce of the channel has changed, and she can start to send messages with the new nonce. It is easy to demonstrate that this is safe for both the sender and the recipient. There is only one condition: the recipient should make sure that the transaction is mined before the expiry time of the channel.

2. There is no race condition between claiming (from the recipient side) and extending/adding funds (from the sender side). The parties can use these functions at any time, and the final result will not depend on the order in which these transactions are mined.

When a user wants to call a given service, they must open a channel, add funds to it, and set an expiry date that allows sufficient time for the service to fulfill its function. Each channel is unique to a combination of client identity (sender), service identity (recipient), and daemon group identity. This allows daemons in the same group to share payment information via etdc, reducing the overall number of channels and simplifying life on the client side. Clients can be end users interacting with the platform via the Marketplace DApp or applications making calls directly or through the SDK's generated code.