Smart contract literacy for the general population

From what I’ve gathered so far, I think there is somewhat of a usability/security issue in general for smart contracts. The only way to be sure the contract does what the creator purports it to do is by reviewing the source TEAL code itself. Non developers won’t be able to do this. So they would resort to client apps that hide the complexity behind pretty UIs and would just have to trust that the client app developer didn’t do anything malicious, such as displaying fake details about the transactions they are about to do and signing completely different transactions behind the scenes. Note that the original developer doesn’t have to be malicious either, in certain client app structures a hacker may be able to hijack the logic.

So to me it seems like there will still be a considerable amount of trusted parties in the ecosystem, even if the infrastructure supporting it is secure and decentralized (like all the dapps that exist out there today). When you sign contracts today, you can at least read into the terms and fine prints if you wanted to. Sure you may not be a lawyer and won’t understand some bits, but I’d think most people will find them more understandable than TEAL code. Is there a way to specify the contract in a manner that’s more comprehensible by the general public? Or is this a moot point and really the fine prints will be on the client apps and they will be regulated and held responsible for any malicious behavior?

The safest way to transact would be for everyone to be able to decipher the contract, and create and sign their own transactions at the low level. But that’s probably infeasible unless we dumb it down enough such that speaking this tech becomes like speaking English… Actually maybe we’re slowly getting to that point with coding becoming a core component in a growing number of curriculums?

I digress. Thoughts?

Maybe Insurance Companies could guarantee, that the site is working according to specified safety standards. The Insurance Company would reimburse you in case of a breach.

Of course this is a super nuanced issue and will become more and more important in the next years/decades etc.

But I think about it like open source code: If someone tries to do something fishy, there will be technical people looking through the source to find it.

I’m using an open source password manager, but I actually didn’t read the entire source code. I’m trusting that since many people are using it, there will be enough people that vet it for exploits.

Of course this isn’t a real solution. An insurance provider like Maugli suggested is a brilliant idea.

Any transaction or group of them will still be spends of some ALGO or ASA. Those spends will all be quite explicit in the transaction to be signed. All statless TEAL code can do is approve or reject a transaction - that’s it.

All good points. Expanding on the fact that TEALs merely approve/disapprove transactions and have no ability to create new ones, and that every client app is a weak point in the trust chain, here’s a suggestion for a safer ecosystem:

We have one simple client app (or very few) that does one thing: sign transactions. This app takes as input pre-constructed transactions. The user may construct them from scratch, or more typically they come from other applications. The app displays the transactions and asks for a signature. Once signed, the app hands over the signed transaction to another app or possibly directly submit them to the blockchain. The signing app should be developed by a trusted developer (or clearly reviewed via open source code) and distributed in a secure fashion.

In this way we don’t care if there are thousands of dapps with their own set of complex logic and vulnerabilities. They never ask for your private key; their job ends when they output a set of unsigned transactions. The attack surface is reduced to just the signing app.

Since transactions are really just movements of assets from A to B, they should be very simple to understand for everyone. It doesn’t matter what the underlying TEAL code is on the contract address you’re about to send to. As long as you like the transactions you see, you sign. The worst that could happen is the transactions get rejected.

But perhaps this is already the plan? Algorand Wallet doesn’t have outside transaction import/signing feature right now, but looks like this is precisely what AlgoSigner or MyAlgo Connect can provide? I think what we need from here on then is to educate people only to sign transactions on their signing app, and not directly on any other 3rd party apps. I imagine an MFA-like workflow would be good. Seamless hand-off to the signing app.

Wrote this mostly for myself. It’s starting make sense now. Thanks for the tips!

MyAlgo Connect provides you exactly this possibility: facilitates users in performing personal audits on the transactions they are going to sign.

1 Like