Merge branch 'docs-refactor' into update-dev-cluster-tutorials

docs/overview/components/composer.md

@@ -1,23 +1,48 @@
 # The Astria Composer
+As a sequencing layer, Astria is designed to provide lazy sequencing for multiple
+rollups. This requires abstracting rollup-specific order flow via the sequencer
+network's transactions, which operate on opaque bytes that are not executed. By
+remaining agnostic to rollup-specific transaction formats, the sequencer network
+is able to provide a robust MEV supply chain for rollups built on top of it,
+with features like native bundle support.
 
-To use a rollup on Astria, users need to somehow submit rollup transactions as
-sequencer transactions to the sequencer network. However, this requires having
-access to two different nodes (rollup and sequencer), as well as having tokens
-for fees on both networks. This is not ideal for UX.
-
-A solution to this is to have a dedicated service that wraps rollup transactions
-as a sequencer transaction and submits them on a rollup user’s behalf. In the
-Astria stack, we have a service called the composer that performs this function.
-The composer only needs sequencer tokens, while the user only needs rollup
-tokens. The user submits transactions as normal to a rollup node. The composer
-picks up these transactions and ensures they are sequenced.
-
-The incentive for the composer is the ability to make bundles of rollup
-transactions, ensuring they are included in a specific order. In this regard,
-the composer can be thought of as a MEV searcher.
-
-The current implementation of the composer is naive and doesn’t perform any
-searching or bundling, although it could be extended to do so. Our hope is that
-the Composer serves as a starting point for searchers and block builders
-interested in collecting end user order flow for one or more rollups and
-submitting it to the sequencing layer as bundles or blocks.
+While the sequencing layer provides a powerful tool for sophisticated users,
+supporting a wider range of users requires additional tooling. The Astria Composer
+is "gas station" side car that makes it easier for ordinary users to easily
+use rollups that support more complex order flow mechanisms.
+
+## The Composer as a UX solution
+While sophisticated users, such as arbitrageurs, can leverage the sequencing layer
+directly to pay for better transaction ordering guarantees, most users will not
+require (or be interested) in this level of control. Specifically, interacting
+directly with the sequencing layer requires users to hold sequencer tokens and
+to maintain a sequencer wallet, both of which result in a poor user experience.
+
+Instead, we provide rollup operators with tooling to abstract this complexity
+away using the Astria Composer. Rollup operators run the Composer as side-car
+software to their nodes. The Composer can be described as a "gas station",
+underwriting the sequencing costs for users' rollup transactions.
+
+This allows order-agnostic users to simply pay for transaction execution in the
+rollup's native gas token without needing to maintain a sequencer wallet, as long
+as the operator keeps the Composer funded. The Composer then bundles these
+transactions and submits them to the sequencer network on the user's behalf.
+
+## Heterogenous order flow support
+This allows Astria-based rollups to support a wide range of users, from those
+who want to pay for better transaction ordering to those with no explicit
+sequencing preferences.
+
+Sophisticated users can submit their transactions directly to the sequencing
+layer, controlling the order by which their transactions are bundled and the
+fees they pay for bundle ordering.
+
+In contrast, regular users are able to route their transactions through the
+rollup node, which will run the Composer as a sidecar to underwrite the cost
+of inclusion but with no control over the ordering.
+
+## Naive ordering preferences
+The Composer provides users with no ordering guarantees, bundling transactions
+by the order they are received. Bundles are capped in size to ensure they fit
+in a sequencer block, and are submitted to the sequencer network in a timely
+manner to ensure they can be included in the next sequencer block.

docs/overview/components/conductor.md

@@ -1,25 +1,25 @@
 # The Astria Conductor
 
 The Conductor can be thought of as the consensus implementation of a rollup full
-node, similar to op-node within the OP Stack. The conductor is run as one half
-on a rollup full node, where the other half is the execution engine. Its role is
-to connect the sequencer and DA layers to the rollup execution layer by deriving
-the relevant rollup transactions for each block and passing them to the
-execution layer.
+node, similar to op-node within the OP Stack. Conductor is the counterpart to
+the execution engine, which together make up a full rollup node. Its role is 
+to connect the sequencer and Data Availability layers to the rollup execution
+layer by extracting the transactions belonging to the rollup node from each
+sequencer block, and forwarding them to the execution layer. 
 
-The conductor’s flow looks like:
-![Astria Conductor](../assets/astria-conductor.png)
+The conductor’s flow is as follows:
 
-For each sequencer block, parse the relevant rollup data it needs validate the
-batch of rollup data; this includes verifying that the corresponding sequencer
-block was finalized, as well as verifying that the rollup data it extracted is
-complete (there are no rollup transactions missing), correct (there are no
-rollup transactions in the batch that shouldn’t be), and properly-ordered (the
-ordering of the rollup transactions matches what was finalized by the sequencer
-chain). It is able to do this by verifying the data against the rollup data
-commitment included in the sequencer block. Once it has validated the rollup
-data, it turns it into a list of transactions, which are passed to the execution
-engine.
+* For each sequencer block, extract the relevant rollup data it needs 
+* validate the batch of rollup data; this includes verifying that the
+  corresponding sequencer block was finalized, as well as verifying that the
+  rollup data it extracted is complete (there are no rollup transactions
+  missing), correct (there are no rollup transactions in the batch that
+  shouldn’t be), and properly-ordered (the ordering of the rollup transactions
+  matches what was finalized by the sequencer chain). It is able to do this by
+  verifying the data against the rollup data commitment included in the
+  sequencer block. 
+* Once it has validated the rollup data, it turns it into a list of
+  transactions, which are passed to the execution engine.
 
 Note that the conductor, like the sequencer, is agnostic to the rollup’s
 transaction format and execution engine; it simply treats transactions as an
@@ -54,12 +54,29 @@ data is actually what was sequenced.
 There is an additional verification step needed: since the conductor doesn’t
 pull an entire block’s data, there needs to be consensus over what rollup IDs
 were sequenced in a sequencer block. It’s possible that a sequencer node doesn’t
-advertise that a rollup ID was included (i.e. by not posting it to DA). Then,
-the conductor would think that it simply had no sequenced data in a certain
-block when it actually did.
+advertise that a rollup ID was included (i.e. by not posting it to the data
+availability layer). Then, the conductor would think that it simply had no
+sequenced data in a certain block when it actually did.
 
 This is fixed by having a commitment to all the rollup IDs sequenced inside each
 sequencer block, which is checked and voted on by every validator. Then, the
 conductor receives a list of all the rollup IDs sequenced in a block and
 verifies that against the rollup IDs commitment to be certain as to whether a
 block had data for it or not.
+
+## Soft and Firm Commitments
+
+The Conductor also retrieves the soft commitments from the sequencer, and firm
+commitments from the data availability layer. 
+
+The soft commitments act as fast pre-confirmations and are implicitly verified
+by the Conductor via a fully trusted connection to the sequencer. All data
+retried from the sequencer is automatically considered a soft commitment because
+that data can't be added to the sequencer chain unless validated by the
+sequencer network.
+
+The firm commitments that are retrieved from the data availability layer are
+considered finalized, and are explicitly verified by the conductor before
+passing onto the rollup. Data that can be retrieved from the data availability
+layer is considered widely available and all historical syncing of data for
+rollups is retrieved in this way.

docs/overview/components/relayer.md

@@ -1,12 +1,12 @@
 # Relayer
 
-The Relayer's responsibility is to take validated blocks from the sequencer and
-pass them along to both the Conductor and the DA layer. Because the sequencer's
-block times are much faster than those of the DA, the relayer also collects a
-queue of ordered sequencer blocks before wrapping them for submission to DA.
+The relayer's responsibility is to fetch validated blocks from the sequencer and
+pass them along to the DA layer. Because the sequencer's block times are much
+faster than those of the DA, the relayer batches the ordered data from multiple
+sequencer blocks before compressing it and submitting it to the DA.
 
-The individual sequencer blocks are sent immediately to the Conductor to enable
-fast finality for an improved UX and also act as soft commits for the execution
-layer. The collections of blocks sent to the DA layer are used as a source of
-truth and are ultimately pulled from the DA to be used as firm commits for
-finality in the rolllups.
+The individual sequencer blocks can also be fetched by the Conductor before the
+relayer has submitted them to the DA. This enables fast finality for an improved
+UX, acting as soft commits for the execution layer. The collections of data sent
+to the DA layer by the relayer are used as a source of truth and are ultimately
+pulled from the DA to be used as firm commits for finality in the rollups.

docs/overview/components/the-astria-sequencer.md

@@ -2,7 +2,7 @@
 
 The Astria Sequencing Layer is a decentralized network of nodes utilizing CometBFT that come to consensus on an ordered set of transactions (ie. it is a blockchain). The unique feature of the sequencer is that the transactions it includes are not executed (lazy sequencing), and are destined for another execution engine (ie. a rollup). This excludes “sequencer native” transactions, such as transfers of tokens within the sequencer chain. Transactions from any given rollup are only ordered on the sequencer, not executed.
 
-The sequencer can optionally act as a “validator”, meaning it actively
+The sequencer node can optionally act as a “validator”, meaning it actively
 participates in the production and finalization of new blocks.
 
 ![Astria Shared Sequencer](../assets/shared-sequencer-overview.png)

docs/overview/introduction.md

@@ -9,6 +9,7 @@ At a high level, the Astria stack performs the following functions:
 * sequences arbitrary data for usage by multiple rollups
 * makes this data available to rollup nodes
 * allows rollup nodes to easily fetch and verify sequenced data
+* batches rollup blocks and posts these batches to Celestia
 
 The first two are mandatory, while the last is implemented more for the
 developer experience, allowing rollup developers to focus only on the