Introducing the DataRegistry, the most boring smart contract in the world
tldr; To hold us accountable, there must be on-chain evidence that proves beyond a doubt that PISA failed to protect the customer. To minimise the hands-on work required for other teams to produce this evidence and integrate with our accountable watching service, we propose the DataRegistry. Its only job is to make it straight-forward (and super-simple) to store evidence that can be used to punish us. We’ll take this opportunity to walk-through how it works.
Do you know of a smart contract that requires the user to watch and respond to on-chain events? Yes? Then we are here to help you!
We are building a missing core component of an open-source financial system, an accountable watching system, to improve the UX of smart contracts. Soon, you can hire us to watch and respond to on-chain events on your behalf. What makes our service different to most others? An on-chain smart contract self-enforces that we are financially accountable for any mistakes.
Let’s say we fail to respond on your behalf. Then you, as the customer, will have indisputable evidence that can prove our wrongdoing. By presenting this evidence to our on-chain smart contract, you’ll kick-start a refund process such that we must refund you a pre-agreed amount before an expiry time.
Why will we refund you? If we do not, then our large security deposit will get slashed. Thus we cannot be evil without suffering financially.
How can I prove your watching service has cheated? There are two pieces of evidence.
First — you’ll have a signed receipt from us that acknowledges the job was accepted (alongside how much we should refund you).
Second — you will have on-chain evidence to show we didn’t do our job.
Wait what? On-chain evidence? How? Read on! This is why we are writing this blog post!
We have spent a lot of time trying to work out the minimal modifications required to on-board smart contracts to use our service.
This brings us to the DataRegistry (i.e. previously hidden away in the appendix of the PISA paper as the dispute registry). It is designed to have a super-simple API and to make it super-easy for smart contracts post and fetch data.
In the context of an accountable watching service — other smart contracts can post logs to the DataRegistry and the PISA contract can follow up by fetching the logs. By standardising the interface for producing logs, we’ll simplify the entire process for smart contracts to integrate with any future accountable service.
Of course — we need to do our best to keep Ethereum healthy — thus all data is eventually deleted from the DataRegistry (for now, lets say every 100 days)
p.s. It may also prove useful to help contracts subscribe to events from other contracts.
How easy is it to integrate the DataRegistry and produce evidence? We have put together a simple example with the MultiChannelContract — of course it is NOT a full implementation, but we have mocked it up to help demonstrate the idea.
In the ideal world — the MultiChannelContract — is responsible for hosting thousands, if not millions, of payment channels. It is well-suited for PISA as all off-chain protocols (and especially payment channels) tend to have some form of challenge period.
All challenge periods have three steps:
- Trigger — One party issues the challenge with evidence to say this action must be executed to update the channel’s state. i.e. Bob may want to withdraw his coins.
- Refute — The counterparty can refute the challenge such that it should be cancelled. i.e. Alice may provide evidence that Bob doesn’t have a sufficient balance to withdraw coins.
- Resolve — If no one refutes the challenge, then eventually the challenge can be resolved and the action processed. i.e. Bob is authorised to withdraw his coins.
In the above, you can hire PISA to watch for the trigger event in the smart contract. If it is a bad challenge, then PISA will perform the refute on your behalf and cancel the challenge.
Let’s look at the code and see how the integration works.
Let’s walk-through how to incorporate the DataRegistry for the MultiChannelContract.
Generally, there are three aspects to consider:
- Organising Channel IDs— How the MultiChannelContract guarantees every channel has a unique identifier.
- Interfacing with the DataRegistry — Essentially, the DataRegistry Interface has a single basic function.
- Posting Logs — How we can post a log from the MultiChannelContract to the DataRegistry using 3–4 lines of code.
Organising Channel IDs
There are two key points for the MultiChannelContract example:
- Every channel has a unique identifier, channelid, which is computed as hash(user1, user2, contract_address).
- The channel “never closes” — it can either be in a resolved (channel is open) or challenge (on-chain challenge) state.
Thus every channel has a single unique identifier which is usable for as long as it has some funding.
Interfacing with the DataRegistry
The DataRegistry only has a single function, setHash, that is used by MultiChannelContract to post logs.
Posting a log. This is a super-simple process. The contract simply passes the channel’s identifier alongside the data. The registry emits the data publicly to notify third parties before storing its hash.
How do we find where the log is stored in the future? The registry returns the data shard and data index. This basically tells us where to look up the data if it needs to be fetched later.
How does the Registry organise data under the hood? The DataRegistry has two simple mappings.
Contract Address (address) -> Unique Identifier (uint[]) -> Data (bytes32[]])
Every smart contract is associated with a list of unique IDs and each ID has its own list of hashes.
Concretely for our example — the MultiChannelContract’s address is the anchor and it is associated with a list of channel identifiers. Then, every channel id has its own list of hashes (logs).
This is why the MultiChannelContract must guarantee a unique ID for every log — to ensure every channel has its own list of logs.
Posting Logs to the DataRegistry
In our example, the modifications for the MultiChannelContract is simple as it is only required to encode data and post it as a log. We only modify the trigger and the resolve functions for posting the relevant logs.
To support web3 wallets, we emit the datashard/index to make it easy to fetch the evidence later if necessary.
We have tried our best to ensure posting logs and making it easy to integrate with PISA requires minimal modifications to the smart contract. There is no need for the smart contract developer to worry about how to store the evidence, whether PISA is watching, or to comply with a standard interface. As long as the data is posted to the registry, we’ll do our best to take care of the rest.
What should the evidence “look like”?
We will cover what data should be encoded for the log in a future post — as this is slightly different for every application.
For this blog post, we really wanted to focus on getting the DataRegistry right and keeping it simple on how to post logs.
So please check out our example code and the EIP we have been working on — it would be great for you to let us know what you think!
First project to support posting evidence? We are putting together a state channel standard about what data should be encoded and how the PISA contract can handle that. Of course, a draft of the PISA code is already online — so an eager reader can already go ahead and see how the evidence can be used to punish PISA.
However… we want to push this log approach for any smart contract with a user liveness requirement.
Thus if you are working on super-interesting smart contracts like auctions — plasma — DeFi — etc where your users must be online to watch and respond to on-chain events, then let us know!
It is very very very likely that if you have a liveness requirement for the user, then PISA can support your service in a financially accountable manner.
If we get it right, then everyone wins with much better UX (i.e. knowing someone will respond for you OR you get refunded) and hopefully it’ll help make it a straight-forward service to implement financially accountable watching services.
So let’s do it!
p.s. If you want to use our accountable watching service without making the above changes… we are still trying to work out how — looks like it’ll require a lot of leg work for both teams… so that is our motivation for pushing this standard!
