61 lines
2.7 KiB
Markdown
61 lines
2.7 KiB
Markdown
---
|
|
title: why is building txs hard?
|
|
draft: true
|
|
---
|
|
|
|
## 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.
|