Trustless accounts or provably locked accounts could add a trustless smart-contract capability for the Safe Network.
I’ve had this idea for a number of years and at one point worked to start up a group with the NXT crypto people to do something similar over there … became disenchanted with that lot though and moved on.
The key concept here is that if you can test an account (or maybe a section can verify such accounts) as being locked to any changes, then that account is limited to the functions/software/apps that are stored there. It can also hold safecoin and transact that safecoin. It could also be used to create new coins on the network for whatever ‘reasons’.
A developer would be able to build their app, website, etc. add some funds maybe, then click a special button and after a couple of warnings and verification, the account would be permanently locked from further access by any user (password provably lost effectively).
At this point the account is akin to an independent corporate entity. It could be used for voting, it could also be a not-for-profit or a for-profit with profits automatically transferring to other accounts or being used to automatically buy some new coin/token - meaning all the coin-holders of this new coin/token are effectively shareholders.
That’s the general gist of the idea and some examples. The concept is different from merely an independent app or smart contract as the trustless account could have multiple apps doing different tasks and all of them working out of the pool of safecoin held by the account.
Thoughts?
Perhaps this is something for down the road post alpha. I don’t know how difficult this would be to implement.
EDIT: It seems this won’t be of any use until we have some basic level of computing built into the Safe Network, so definitely down the track. Thanks @neo for helping me understand this better.
In order run APPs against an account you need a computer. That requires it to be logged into that account.
I think you will find what you want done will come with compute
The APP developer has no access to the account the APP is being run against unless the account owner allows it. The APP does not run against the APP creator’s account
What I am saying is that who cares who made the APP. Once the APP is there to be run then it has no access to the account of the person who wrote it. Only if the account keys are in the APP would that be possible and stupid too.
I’m guessing that you’re saying that the user running the code can change the code while on their computer.
While I agree that they could do so, the code itself can’t be changed at the source I’d think - not writable, just public readable … so for most people using the app this probably wouldn’t be an issue.
Okay gotcha now … so it could deposit to the account I guess, but no way for any app to pull from it until compute option on Safe?
It is their account that the APP uses when reading/writing data and using any required keys (when allowed). The APP writer is irrelevant in this process. The APP runs as you, not the developer.
If the developer includes other keys in their code then yes they could work on other’s accounts but that is dangerous and stupid.
It may. This part is to prevent a specific attack on Elders. The key selling attack. It works like this. A bad dude puts up a website to “buy” vault/routing/quic-p2p keysets from people who have an Elder machine. If the people agree to sell these then the bad dude may get to control/stall a section. There are several options open to us and quic and the likes helps (like detecting IP moved and so on) and one option is the routing identity keys are run from a secure enclave. In that way users do not get to see the private key to sell to the bad due.
As you say it makes compute easier as well, as it transforms a byzantine issue in to a crash tolerant issue as we could have code in there that we know is not malicious and so on. This part is more work that just the keys being there.
So not designed out, but it could mean elders must be able to pass remote attestation checks to confirm they have no access to secret keys. It is in the roadmap to allow us to confirm, we wan this and also to check the pros and cons (con being not all cpu manufacturers have a TEE and cross platform capabilities are limited (mind you Microsoft have open enclave)).
This library [quic-p2p] enables stateless-retry to defend against IP spoofing. This is achieved by sending a token back to the connecting node which must be returned. quic also defines a protocol negotiation process that defend against many attacks by confirming the acceptable protocols.
Another showstopper con is that all known current secure enclaves have proven to be much less secure than advertised - basically open books thanks to speculative execution attacks. Even if those are patched the future outlook does not look good. The bad dudes offering to buy your keys will also provide the script to scrape them out of your own machine’s “secure” enclave. Leave them running as root with no time pressure. I really hope we find another clever way to address this attack perhaps leveraging multisig…
Yes, this is true, however, it is an option to improve security in some ways. Not blind acceptance of all code in this case, but merely the secret key defence alone. We will get to this, but the economic incentives that also protect miner collusion etc. all make a difference. The secured section messages now buys us a lot here. don’t want to go too deep otherwise we take out eyes of the short term prize, but we can likely detect a malice section and replace it easier than using TEE. Right now I am focused on getting the teams all in the project execution plan and that means a huge focus. So this does not worry me as I think it is very much solvable. As you say though, even multisig helps (BLS is a big win in this industry).
The other main negative concern about leveraging Trusted platform technology for the Safe Network is a moral one. As outlined here, with summary over here that scratches the surface of the moral issues. See Chapter 3 “Implications of Trusted Computing” for real debate and insight.
The most common counter argument when this tech first made mass coordinated entrance onto our machines was “it is just another tool” which had some merit. The Safe Network would be using it as just that - a tool - but with side effect of requiring us all to have a TPM module just to play. We are already seeing that calling it just a tool was at best disingenuous - it has been the thin edge of the wedge tech that has allowed third party software to take power, control and privacy away from owners of hardware despite all the positive use cases. It did not have to be this way however but was a dark pattern design decision (see previous pdf).
Not that the majority of consumers care, but there are still some of us when given a choice will choose the increasingly hard to select “NO TPM module” when making purchasing decisions…
This would not necessarily be the case in any plan. If we ever did use TEE then all I can see so far is Elders would be required to have that capability. So potentially 100% of nodes could not to be Edlers, but 100% of nodes will farm. So it is not black and white, also the open enclave project like others is looking at intel arm and AMD as well as a software only enclave (interesting). So the point here is this is a tool, it need not be blindly applied to all (as that is bad all round), but may be useful going forward. We have not instigated the research project for this yet, but eyes open is important. So digging is good, but we must dig the good, bad and the rest about all these technologies. If you add in AI, etc. there is a lot, but as the network grows it will need to choose wisely
