60 lines
2.7 KiB
Markdown
60 lines
2.7 KiB
Markdown
---
|
|
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.
|