You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should build contracts that attesters can inherit to easily get certain functionality. Some things I think would be useful:
1. Contract that re-imburses the cost of executing attestations from a budget
An attester could inherit this contract to allow callers to be reimbursed. This would make publicly funding the operation of attesters more modular and transparent. e.g. an attester could directly get operation funding from a gitcoin round.
2. Contract that establishes an ether bridge
An attester could inherit this contract to allow epoch keys to receive ether. This would require 2 user data fields to be reserved for balance tracking (could potentially be 1 field with two 128 bit subfields). The contract could expose the following:
e.g. ethereum addresses can send funds to epoch keys and epoch keys can send funds to ethereum addresses and other epoch keys.
3. Epoch key safety
An attester could inherit this contract to track which epoch keys have been proven to exist in which epoch. This would allow epoch key proofs to be re-used more safely/easily.
e.g. when an epoch key is proved to exist in an epoch, a mapping is updated
Epoch keys are globally unique so each epoch key has 1 epoch. If/when this is revealed we cache it. When an attestation is made to an epoch key we check the cache to make sure it has been proven to exist in the target epoch.
The text was updated successfully, but these errors were encountered:
We should build contracts that attesters can inherit to easily get certain functionality. Some things I think would be useful:
1. Contract that re-imburses the cost of executing attestations from a budget
An attester could inherit this contract to allow callers to be reimbursed. This would make publicly funding the operation of attesters more modular and transparent. e.g. an attester could directly get operation funding from a gitcoin round.
2. Contract that establishes an ether bridge
An attester could inherit this contract to allow epoch keys to receive ether. This would require 2 user data fields to be reserved for balance tracking (could potentially be 1 field with two 128 bit subfields). The contract could expose the following:
transferTo(uint epochKey) payable
transferFrom(uint[] memory publicSignals, uint[8] proof)
e.g. ethereum addresses can send funds to epoch keys and epoch keys can send funds to ethereum addresses and other epoch keys.
3. Epoch key safety
An attester could inherit this contract to track which epoch keys have been proven to exist in which epoch. This would allow epoch key proofs to be re-used more safely/easily.
e.g. when an epoch key is proved to exist in an epoch, a mapping is updated
mapping (uint => uint) epochKeyEpoch
Epoch keys are globally unique so each epoch key has 1 epoch. If/when this is revealed we cache it. When an attestation is made to an epoch key we check the cache to make sure it has been proven to exist in the target epoch.
The text was updated successfully, but these errors were encountered: