Q: How do we differentiate transactions with different costs (e.g., TX using 1KB vs. 1000KB storage)
To answer this question, we must first understand who can deploy smart contracts on Orbs. Smart contracts are always deployed in the context of a virtual chain. This is an isolated context because different virtual chains use different resources and do not affect each other. For example, regarding storage, every virtual chain has its own separate storage which is billed separately in monthly cycles according to the relevant subscription tier (for example, 10GB storage costs X ORBS tokens, 100GB costs Y tokens, etc.).
When a virtual chain is created, its creator can limit who can deploy new smart contracts to it. For virtual chains that are dedicated to running off a specific app, it makes sense to limit smart contract deployment to the developer of the app only. This gives the app developer full control over which contracts run on the virtual chain they are subsidizing. These contracts are free to incorporate logic that rejects executions that are considered spam and consume too much resources.
This business model has been proven for consumer apps on traditional cloud providers like AWS, where the app developer deploys the backend code to their virtual machines and is free to reject requests by users if those are considered spam. In most consumer cases, the app developer will subsidize infrastructure costs to all users ignoring the nuance of much resources each user consumed. Consider a chat messenger — users can send images to their friends, but it doesn’t matter if a user sends 10 images or 100 images. Users will only be blocked if they are marked as spam (sending over 10,000 images in one day for example).
There are some cases where the creator of a virtual chain requires more control over which transactions are executed and how. This is the case for example when an app developer wants to fund the virtual chain subscription from user transactions. This is possible in Orbs through programmable fee models.
Consider an Airbnb app where users pay a contract a relatively large amount to rent a vacation property. The app developer can decide to allocate 1% of the amount transferred as a fee to help fund infrastructure costs. Since this logic is custom per app and its unique business use case, it is implemented as an auxiliary smart contract on the virtual chain which runs before a transaction is approved. We’ll cover this feature in more detail in a separate post.