Hello everyone,
In my quest to fully understand Cardano I’ve come up with some issues, as well as a possible fix. Please forgive me if these issues were addressed at the conference last month, or elsewhere in the forum (I couldn’t find exactly what I’m proposing here). Please also forgive my potentially faulty understanding of the Cardano ecosystem, as well as my abuse of the ‘O()’ notation :p.
Perceived problem(s)
- I assume Daedalus uses one of the IOHK nodes for tx-submission/chain-sync. This isn’t really decentralized.
- Similarly I assume Yoroi uses a not-so-decentral Emurgo server.
- I assume Daedalus uses the unencrypted Cardano node-to-node TCP-based communication protocols. Without a VPN, ISPs/governments could easily trace these txs back to individual users.
- The node-to-node TCP protocols seem unsuitable for large-scale use by client-like nodes (i.e. ‘leechers’ in p2p terminology). The network guidelines state that each full node should maintain O(10) hot connections. With around O(1000) publicly discoverable full nodes, only O(10000) simultaneous node-to-node connections are possible. These connections seem to be designed to be long-lived (>1s). Cardano goals are clearly far greater than O(10000) global client requests per second, and it would be nice to serve those in a decentralized fashion.
- Cardano on-chain ‘smart contracts’ (i.e. validator scripts) aren’t really smart. They require significant amounts of off-chain programming to be able to do anything useful. Sometimes the relationship between the off-chain code and the wallet is quite intricate (see example at the bottom of this post).
- Cardano DApp off-chain code seems to require running a full node. Average Cardano DApp users won’t want to install that themselves, so they will use DApps hosted by some third-party. This isn’t really decentralized and makes the ‘D’ in ‘DApp’ a misnomer.
Solution
Each stake pool could opt to host a REST API ‘gateway’ over HTTPS. The address and port of the gateway could be included in the stake pool registration metadata.
The gateway would be similar to cardano-http-bridge (is this still maintained?).
In addition to cardano-http-bridge endpoints, the following endpoints are nice-to-have:
- An endpoint to list only block ids that are relevant to specific addresses
- An endpoint to list block ids containing stake pool registration info
The gateway would be trustless, and, combined with Mithril, wallets using these two extra endpoints would be fast, validating only the blocks relevant to the wallet user.
To avoid resource consumption attacks, the gateway could restrict access to users who prove they have some minimum stake with the given stake pool. Upon authentication, this proof could be included as a token in the header of each HTTP request. Tokens could be shared with friends to provide a bootstrapping mechanism. The gateway access control would need to perform throttling for every authenticated user.
Stake pool operators could use the HTTPS gateway service to attract new stake holders. Stake holders valuing increased decentralization would prefer delegating to stake pools that provide this service.
How this solves problems 1 and 2
I assume both Daedalus/Yoroi will implement HD multi-pool staking at some point. After initial bootstrapping, these wallets will thus have a range of gateway servers to choose from for tx-submission/chain-sync.
How this solves problem 3
HTTPS is encrypted by definition. The tx-submission request could even be given an additional layer of privacy by specifying a submission delay and a node hop count. This would make it nearly impossible for ISPs/governments to infer the indentity of a user based on the tx time, without the need for a VPN.
How this solves problem 4
Most client requests will be polling for chain updates. With a good caching architecture each gateway should easily be able to handle >1000 of these requests per second.
How this solves problems 5 and 6
Interfacing with a REST API is extremely simple, and everything can be done with in-browser javascript. This would be a huge improvement of the Cardano developer experience, and a large number of developers would easily be able to create serverless single-page wallets, integrated with some core DApps.
I think wallet development would become a much more interesting and competitive space, and much easier to audit (assuming use of a standard cryptography library). Currently I need to rely on the developers of a small number of hard-to-audit wallets (Yoroi, Daedelus, …) to integrate the DApps in the convenient way I want.
The wallets could be hosted via IPFS, making the wallet software itself decentralized and uncensorable. The gateway could even enforce this kind of decentralization by disallowing request origins that are not ipfs:// addresses. Of course I assume here that mainstream browsers will implement the IPFS protocol in the (near) future.
A number of core DApps could be integrated in these decentralized wallets (eg. the ‘last will and testament’ smart contract example below). I predict these wallets would end up looking like modern bank websites, easing mainstream adoption due to the similarity. They could also be installed on mobile devices as PWAs, making them uncensorable by app stores.
Example of intricate relationship between off-chain code and wallet: last will and testament
Let’s say I want to implement a ‘last will and testament’ smart contract.
It would allow my heirs to transfer my assets after a certain time of inactivity (eg. 2 years).
It also provides a fallback in case I lose my wallet key.
In Cardano the on-chain validation scripts can’t detect wallet inactivity though. So instead, when ‘installing’ the ‘smart contract’, I would send the assets to an address of a time-lock script. This time-lock script would release the funds to my heirs after 2 years.
If the off-chain code detects activity before the 2 years are over, it would send the assets into a new time-lock script, effectively extending the deadline. (Alternatively the assets could be resent to the same script address using a different Datum).
To prevent excessive tx fees, the off-chain code would only do this update every 12 months.
I can think of two reasons why this contract should be managed by the wallet itself.
1. Simple spending of assets locked in the contract
I want to be able to spend the inheritable assets at any time. This means that these assets would preferably still need to be managed by my wallet.
It would be inconvenient and wasteful to do this via a third-party DApp. The assets would need to be sent back to an address controlled by the wallet before being spent. As a consequence a wallet that is 100% covered by a third-party ‘last will and testament’ would effectively double my tx fees. Alternatively the DApp would have to provide wallet-like functionality and be able to generate the spending txs I want.
(I doubt any DApp-connector will ever be smart enough to detect that assets are locked in a contract that also allows the owner to simply spend them, and thus spend them using a single tx.)
2. Detecting activity and automatically extending the time-lock
Detecting activity and automatically extending the time-lock is trivial when the ‘last-will and testament’ is managed by a wallet.
But a third-party DApp would require me remembering to log into their service. Or alternatively the DApp would need to poll the blockchain for txs emanating from my staking addresses, and then send me a reminder. Next I would have to submit the time-lock extension manually.
If I live for another 30+ years, will the DApp server still be running then? Will I remember to keep doing this manual operation every year? Will email even still exist? (though messaging could be done via Cardano I guess)