TApp Txn Requests: Updating the State Machine
As we covered in the previous post, TEA hosting nodes run the various WebAssembly binaries that form TApps. These are serverless lambda functions that can be categorized as either queries or mutations.
These hosting nodes run function calls on behalf of TApps that also generate transactions. Recall that transactions sent from the hosting nodes can either be queries or mutation requests (a mutation request changes the state). The logistical difference between these two is as follows: mutation requests must be sent to the state maintainer nodes, while query requests may or may not be sent to the state maintainer nodes. Let’s dive deeper into both starting with mutation requests.
Mutation Requests
A mutation request from a hosting node generates a transaction that gets sent to the state machine. At least two state machine nodes will pick up the txn, process it, and add the transaction to the conveyor belt. The conveyor belt sorting algorithm will order the transactions coming in from the various state machine nodes to reach consensus on the proper order using the transaction timestamps.
In total, the transaction chain for a mutation call looks like this:
- Hosting node dispatches mutation transaction (that changes the state) to the state maintainer nodes.
- The state machine actor will execute the transaction and update the state.
- The hosting nodes are constantly querying for the updated state.
Any state updates will be sent to the front-end of the TApp where the end-user can see the updated result.
Query Requests
While hosting nodes are able to send queries to the state maintainer nodes for the latest state, these query requests will only be sent directly to the state nodes in rare circumstances. If a query transaction is sent directly to the state maintainer nodes, then a state actor will query the state. The state response is sent back to the state actor which eventually makes it back as an update to the front-end of the TApp.
But as we’ve mentioned, querying the state maintainer nodes directly will rarely be necessary as hosting nodes have more economical options. Note that every hosting node will cache a historical version of the state in their own node. Their version of the latest state will be updated through other hosting nodes that act as secondary state maintainers using a state subscription model. Under the state subscription model, the original state maintainers will broadcast to a limited number of hosting nodes in order to reduce the network bandwidth consumption and speed up the entire workflow. These hosting nodes will then broadcast to the other hosting nodes on the network thus saving the network from the bottleneck of too many hosting nodes pinging the state maintainer nodes for the latest updated state.
The hosting nodes who pay to become the state maintainers immediate broadcasters are known as seated hosting nodes. We’ll describe the mechanism of these seated hosting nodes in the next section.
The State Chain: Seat Maintainer Nodes -> Seated Hosting Nodes -> Unseated Hosting Nodes
The TEA Project views its state maintainer nodes as a limited resource. Based on that POV, developers have to pay a memory tax to use the state machine memory. Additionally, state maintainer seat holders have to pay a tax based on their self-valuation of their seat’s worth.
Because state maintainer nodes are a limited resource, we have to encourage the hosting nodes to get the latest state updates without overwhelming the state maintainer nodes. With this in mind, the TEA Project also has the concept of seated hosting nodes who broadcast the latest state to other hosting nodes.
- Seated hosting nodes = pay for a state subscription to get the latest state updates before the other hosting nodes.
- Unseated hosting nodes = get state updates for free from the seated hosting nodes. There’s a slight delay compared to when the seated hosting nodes get the latest state as they wait for the seated nodes to broadcast and propagate the latest state to the unseated nodes.
The hosting nodes can become seated by purchasing a state subscription seat via an auction. This has an associated Harberger Tax based on the self-valuation price.
TEA’s state machine is a complicated topic and this post has only touched on some facets of it. If you’d like to learn more, please check out our other posts on the TEA Project’s database tier and our state machine.
And make sure to visit our Telegram if you have any questions: https://t.me/teaprojectorg
