TEPs
TEPs copied to clipboard
ton-blockchain
TEP: Trusted off-chain Execution
This proposal introduces a way to perform expensive or private computations off-chain that could be trusted by a smart contracts or end-user apps.
- What additional op-codes do we need to be able to check attestation documents onchain? I guess something for certificate path (X.509)? Lets imagine we want to proof that some site gives some response, for instance we want to get price of some asset from public API of given exchange. I guess we need a verified image which makes request to time-server before, request to api, request to time-server after and compose response with price and time.
- Then contract gets attestation document. What should be done after that? Contract should check that image hash coincide with trusted one, there is a valid path from some trusted root certificate to public key and key is signing the attestation doc?
- How trust will be theoretically distributed in this case? We need to trust Linux kernel, specific executed program, AWS (that it didn't malevolently forge data or accidentally compromised a certificate), and data provider, right?
The big issue I think is that this introduces a strong dependency on AWS since Nitro is the only truly viable solution at the moment.
Effectively, by using this service we let AWS Ltd vouch that this code is indeed what's running. This is great and all, but introduces a pretty heavy centralized dependency on a US company, which can even introduce censorship later on.
We've seen cases where companies, particularly in the US, introduce limitations - whether it's data centers that suddenly announce that their servers cannot be used for crypto-related mining or validation, or service providers that get a court order from a specific local regulatory body to censor a specific on-chain protocol (eg. TornadoCash).
I don't think it's a coincidence that technologies like Nitro are not widely used in decentralized ecosystems. Nitro is available for a long time. Validators of pretty much any blockchain protocol could have benefited from relying on it - TON core validation included (TVM execution result could have a similar attestation to convince that a TON transaction was indeed executed correctly). Yet we see the decentralized community is not embracing these solutions.
We could introduce this layer as an extra layer of optional trust. But a layer that we could lose later on and nothing will happen. For example, with the contract verification spec, allow multiple decentralized participants to validate sources. Some will use Nitro but some will not use Nitro explicitly - nor any other centralized trusted environment. I am planning to publish a TEP about this method, that we're been actively working on for the past few weeks.
I believe AWS Nitro is the only easily accessible solution, but some embedded execution environments also provide attestation methods. Eventually, we can have distributed hardware that verifies and executes code, just like validators.
Nitro IS used widely, just not for this purpose. It is precisely used for validation of some blockchains (CRO) since the code is verified and not altered, and this provides extra protection.
This layer is optional indeed; later, it could be some webassembly-based VM that could run anything off-chain and then could be signed by a distributed group of machines, just like current bridges are. I just don't see the economics of this thing.
I'm not sure that any embedded execution environment is significantly different than Nitro.
At the end of the day there is a short list of trusted manufacturers, that use their embedded private keys inside some tamper-proof hardware device to sign the attestations for code executed by the hardware device. Our community will then buy this hardware, and trust the manufacturer, and use the hardware to provide the attestations. This list of trusted suppliers is eventually centralized. They were not chosen because they're part of any TON-related incentives model. It will probably be large companies with a lot to lose, not very sympathetic to our causes. One letter from the wrong body and they would stop being cooperative.
Also this would prevent most community participants from taking part of this attestation process because it would require specific hardware to be purchased, prevent most cloud environments and so forth.
What additional op-codes do we need to be able to check attestation documents onchain? I guess something for certificate path (X.509)?
Yes, we need to verify certificate chain with, it could be some version of X.509 in tl-b. I am not sure about the details, maybe another service that somehow verifies these attestations and replaces them with a simple signature, just like Verite works.
Lets imagine we want to proof that some site gives some response, for instance we want to get price of some asset from public API of given exchange. I guess we need a verified image which makes request to time-server before, request to api, request to time-server after and compose response with price and time.
A verified image is built by a contract developer that wants to utilize this feature, it builds it, publishes sources (optional), and then embeds the image hash into the contract code. Upgrades to the image could be done by updating the hash.
Then contract gets attestation document. What should be done after that? Contract should check that image hash coincide with trusted one, there is a valid path from some trusted root certificate to public key and key is signing the attestation doc?
Yes, for AWS Nitro there are root certificates published in AWS docs.
How trust will be theoretically distributed in this case? We need to trust Linux kernel, specific executed program, AWS (that it didn't malevolently forge data or accidentally compromised a certificate), and data provider, right?
Yes, but this guaranteed behavior is insured by AWS SLAs. They are using custom-built hardware for virtualization to make everything secure, and they just expose attestation to the app. I carefully reviewed their practices, I don't think that this is a real threat. At least, if you can forge this hardware you can make much much more money than forging TON's contract source code verification.
I'm not sure that any embedded execution environment is significantly different than Nitro.
At the end of the day there is a short list of trusted manufacturers, that use their embedded private keys inside some tamper-proof hardware device to sign the attestations for code executed by the hardware device. Our community will then buy this hardware, and trust the manufacturer, and use the hardware to provide the attestations. This list of trusted suppliers is eventually centralized. They were not chosen because they're part of any TON-related incentives model. It will probably be large companies with a lot to lose, not very sympathetic to our causes. One letter from the wrong body and they would stop being cooperative.
Also this would prevent most community participants from taking part of this attestation process because it would require specific hardware to be purchased, prevent most cloud environments and so forth.
Even now, Taiwain sells chips to Russia that could be used in rockets; I don't think that this would be easy to disrupt the supply chain here. Also, there are multiple manufacturers, and now we can even build our chips in our lab. It is not that expensive.
Clouds wouldn't work, but someone will build one to support this custom hardware.
Even if you could build such a chip in your lab, everybody will just have to trust you that you built the chip correctly... It's not much different from you running a centralized service on your private server and the community trusts you in general that you're executing what you're promising that you're executing.
The model would only work if we had a large group of decentralized validators that each could build their own chip in their own lab. And this is of course an overkill, we might as well have them each run their own centralized server without any attestation. Which is what most blockchain protocols essentially do :)
I disagree; ultimate protection is impossible - you can always buy 100m+ coins somewhere or "hack" a TF multisig wallet for much less; you can just find owners (they are not that secret) and enforce them to give up the keys and then stake all these coins and start to censor network.
It is all much easier than trying to hack strict AWS policies.
The PR you proposed is much inferior, and we just trust another verifier service as well.
With this reasoning we don't need validators on TON at all, we can just move everything to AWS
Using my proposal, you can have some verifiers that give AWS signed attestations as extra optional trust and have others that do not depend on AWS to maintain the ethos of the ecosystem. The most important thing is not to create a dependency on AWS