Skip to content

zkChannel contract optimizations

Jump to bottom
Darius Parvin edited this page Nov 12, 2021 · 1 revision

zkChannel contract optimizations

Hash optimized smart contract - tezos-contract: optimize-with-hash

Description: Replace the merchant Poincheval-Sanders pubkey from the initial storage with a SHA3 fingerprint. Then, pass the pubkey as an additional argument to the custClose entrypoint call. The hash is calculated by: sp.sha3(sp.concat([y2s_0, y2s_1, y2s_2, y2s_3, y2s_4, x2]))

Zeekoe implementation

In order to implement the hash-optimized smart contract, the following changes to zeekoe need to be made (in addition to updating the smart contract itself):

For the customer:

  • The initial_storage for originate needs to be edited. Replace the PS pubkey fields with the value of merch_ps_pk_hash.
  • The entrypoint to cust_close also needs to also include the PS pubkey fields. For the merchant:
  • verify_origination should check the value of merch_ps_pk_hash instead of the PS pubkey fields.

Multichannel contract

Description

Our current implementation of zkChannels on Tezos uses one smart contract per channel. Instead, we should be able to use one smart contract per hub (merchant), with each channel being an entry in the smart contract.

Smart contract design

Storage

The contract's storage will contain merchant-specific information, and a data structure to store the list of channels and their details:

  • Merchant-specific data: merchant_addres, merchant_tezos_public_key, self_delay, merchant_ps_pk_hash. (merchant_ps_pk_hash as with the optimization above, or the full set of PS pubkeys)
  • Channel specific data:
    • We haven’t looked into what data structures are available/suitable to use in Michelson, but it may be suitable to use a map. Ideally the data would have the following structure:
1{ 
2  channel_id : 
3    {
4    customer_address, 
5    customer_balance, 
6    merchant_balance, 
7    revocation_lock, 
8    status, 
9    delay_expiry,
10    },
11}

Entrypoints

Calling entrypoints would be the same as before, however, the data being accessed and manipulated would be within the channel-specific data structure. zkChannels protocol

  • Origination - Origination would happen once by the merchant as part of their initial setup.
  • Channel establishment - Instead of the customer originating a new contract, they will create an entry in the smart contract by calling an entrypoint (e.g. establish) with the arguments from 'Channel specific data' and funding it with the amount specified in customer_balance. If the amount included in the transaction is not equal to customer_balance, the contract will fail the operation.
  • Closure - When a channel reaches the CLOSEDstate , its entry could be deleted from the contract.

Other considerations

  • The merchant may want a global expire entrypoint to initiate expiry on all channels, e.g. expireAll.
  • There is likely a maximum storage size for any smart contract. Some things to consider if so:
    • It would limit the number of channels a contract could serve. If this is an issue, it may be possible for the merchant originate multiple contracts to serve the same set of customers without compromising the unsinkability of their payments.
    • Care must be taken to make sure that calling entrypoints does not add any additional bytes to the contract. Otherwise a channel may get stuck if it is unable to close.
Clone this wiki locally