2.7 KiB
title |
---|
why is building txs hard? |
What is a dapp?
A typical dapp has a number of components:
- Validators: also called the on-chain part. The decentralized network of nodes that maintain the chain run this code as part of the process of deciding whether a tx is to be added to the chain or rejected.
- Chain indexing: watches the chain and records the data relevant to the dapp.
- Pretty front-end: typically how a user interacts with a dapp.
- Tx-building code: A component of the frontend. It takes data from the user, the user's wallet, the chain-indexer and possibly elsewhere to construct txs to be submitted to the chain that the validators will deem acceptable.
Here we have really described a browser-based plutus dapp. Considering the term dapp more generally, the Daedalus wallet is a dapp which is neither browser based nor involves any Plutus. Cli-based dapps also exist, such as multi-sig using native scripts.
What is a tx?
At its core, the chain is a list of transaction outputs. The chain is changed by submitting a tx which "spends" existing unspent transaction outputs (utxos) and appending new ones. (There's other possible modifications too, like minting native assets and staking etc, but the key part is spending.)
The on-chain part is where the dapp has its integrity, but users can only interact with the on-chain part of the dapp by submitting txs.
The on-chain part is relatively simple. It inspects each tx that it is concerned with, and if it does not like what it sees, it fails. Cardano is, in this sense, a lean chain.
The off-chain part is relatively complex. There may be no, one, or many potential valid txs that would satisfy the user's intent.
At its core, a transaction is a list of inputs and outputs. The inputs are spent, and the outputs created. It must also contain the necessary signatures.
Some history
When Plutus was first dreamed up, it wasn't just a language. It was whole environment in which dapps would be engaged with. The on-chain and off-chain code were coupled into a single framework with seamless extensive testing. Dapps ran in the PAB, Plutus Application Backend. Everything was great.
Except that it didn't work. The chain-indexer would periodically fall-over, it required users had to maintain a full node, and the api never matured in to something stable, complete, and bug-free. In addition, the validators it produced were bloated and un-optimized and would quickly hit the constraints of the cardano blockchain.
As a result teams turned to coming up with alternatives. One of the first was MLabs and co in creating pluto and plutarch. Later Aiken appeared to meet similar needs. These began resolving issues with the on-chain part. This left the off-chain part wanting.