Client-side TX Generation

[tspoff]

Tl;dr:

• With a few changes in Lumos, we could do TX generation client-side, accessing indexed cells via a simple server.
• This indexer server could become a standard infrastructure component, like a node.
• This way dApp developers wouldn’t have to make their own server if their app didn't have intensive bandwidth or compute requirements. It also increases decentralization and could make learning easier.

Client-side TX Generation in Lumos

I’m thinking about reducing development work and increasing decentralization for the dApps that are built with Lumos framework. Especially for people just getting familiar with the Nervos platform.

Lumos, as currently designed, encourages each dApp developer to write a custom server that contains the bulk of the logic for their dApp. This is because Lumos is intended such that the entity that handles TX generation needs to be the same as the entity running the indexer.

I’ll show how the flow of a transaction looks currently on lumos, and show a model where things happen in a heavier client, freeing the dApp developer from having to write, run, and maintain a second application (the custom server). The lack of a custom server intermediary also potentially improves decentralization.

Current Flow: Tx Generation on Server

The flow of a user action looks something like this:

• The user expresses an intent to perform an action on the client.
• The client asks the dApp server to generate a TX, in response to this action.
• The dApp server does this, using a locally running indexer to get cells.
• The server forwards the raw TX to the client.
• The client acquires signatures from the wallet.
• The TX + signatures are forwarded to the server for sending to the blockchain.
• The server or client may also want to keep track of the transaction hash to see the TX status on-chain. This can be forwarded from the server.

Additionally, read requests (such as for cells or balances) are routed through the server.

Alternative: TX Generation on Client

The dApp client could do TX generation on its’ own, if it had access to an indexer to query for cells. A simple, stateless server running the Lumos indexer could provide a source to query directly for cells. In this model, you can think of the indexer as an infrastructure service, akin to a node, that can be run by anyone. This stands in contract to a custom server.

In this model, an action flow would be:

* The user signals an action on the client.
* The client generates an appropriate transaction, using cells queried from the indexer server.
* The client gathers required signatures from the wallet.
* The client sends the transaction directly to a CKB node.
* The client can track the status of the transaction via a subscription to a CKB node.

The client could also collect cells for displaying balances from an indexer, or perhaps get this information from the wallet for the active user.

Performance

I don’t expect that bandwidth or compute requirements will be significantly increased for a large percentage of dApps (Compared to a web2 app with similar amounts of data, or the dApp server model). Some applications that deal with a lot of data at once, such as analytics platforms, or that require intensive TX generation, will likely benefit hugely from the dApp server.

Caching information

Derived information is essential for users to make sense of what’s happening on CKB. There should be a client-side caching layer that’s easy to set up with this model.

• Gather certain cells on load to form an initial data set, such as user balances.
• Keep track of changes, and apply them to the existing data, as new blocks arise.

Open Transactions: A Cavent

For dApps that involve open transactions, there will still need to be some sort of aggregator (custom service) that holds state about the current transaction fragments.

• The dApp owner can provide this service, because they care about the app functioning.
• This could also be more decentralized with IPFS-hosted data + incentivized aggregators.

[xxuejie]

I do believe what you explained here could be super useful. It is also why I maintained ckb-js-toolkit as a separate library. However, lumos is designed from day one to only run in node.js environment. There might be some parts that we can refactor and split to a separate module, but lumos here, IMHO, is better suited as a node-only framework.