---
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.
