Athena Transactions journey

Research
,
1

Transaction flow:

Let’s take the simple transaction example: Alice paying Bob

  1. Alice opens her wallet, creates a transaction which sends money to Bob, presses enter and it’s done. Alice has only an Athena account and funds in this scenario and no L1 account. Alice can also be a sophisticated user and become a relay herself which means she has an account in both Athena and L1.

  2. The wallet needs to gather specific information from the network and Alice:

  • Current Execution Price: The wallet downloads the current gas price required for transaction execution.
  • Storage fee (storage fee is paid to miner and execution fee is paid to executor). A part of the payment will be to pay relays since it’s the relay who pays for storage.
  • Nonce and Balance: It retrieves Alice’s account nonce and the balance to ensure the transaction can be processed.
  • Receiver’s address (Bob) and amount to send from Alice and her key to sign the transaction.
  • Expiration time can be a default value from the wallet or customized by Alice.

  1. Wallet estimates cost and displays it to Alice (Alice does not need to know the details of fee but only the maximum total price) this might cost so she confirms the amount.

  2. Alice confirms the price to pay.

  3. Wallet sends Alice’s transaction to the relay mempool where it will be stored as an unconfirmed transaction.

  4. Relays parse Alice’s transaction and other transactions from the relay mempool to verify if users have the necessary funds and decide whether to sponsor them.

  5. Relays select transactions, forming bundles to broadcast to the L1 mempool.

  6. Transaction Deduplication: Bundles are deduplicated in the unified block creation process. Deduplication removes redundant transactions, optimizing storage and processing.

Relays

Relays are responsible for collecting and bundling Athena transactions into groups. They ensure these transactions are ready for inclusion in the L1 blockchain. This includes managing the initial processing and sorting of transactions to form coherent and executable bundles which are then deduplicated in the unified block creation. A relay mechanism requires relays to have liquidity in L1 for storage fee payment. Athena transactions and users balances are completely opaque to L1 miners.

  1. Relays start by gathering transactions that users submit to the relays mempool (This is a different one from the L1 mempool).

  2. Parsing and initial validation : Relays parse users transactions (format check, Deserialization) and verify users Athena signatures and balance to ensure users have the necessary funds and decide whether to sponsor them ensuring only valid transactions reach the L1 mempool.

  3. Bundles: Once transactions are validated, they are included in bundles

  4. Submission to L1: Once a transaction bundle is ready, the relay is responsible for submitting it to the L1 blockchain.

Random Selection of Relays:

Using randomness, Hare participants will assign transactions to relays. This helps in reducing the storage burden and ensures that each transaction is linked to only one relay, so for every transaction there is only one relay selected because it’s more efficient in terms of storage. Relays pay storage costs only for transactions they are responsible for, preventing duplication.

Deduplication Process:

Before relays are randomly assigned to transactions, a deduplication process occurs. Deduplication removes redundant transactions, optimizing storage and processing. This means that even if multiple relays include the same transaction, it is only stored once. Miners use the same Hare mechanism as for L1 transactions to recognize and remove any duplicate transactions.
Bundles are deduplicated in the unified block creation process.

Fee Management, Cost and Reward:

Transactions specify two types of fees: one for the relay and another for execution. The relay fee covers indirect costs such as L1 storage and gas proxying between L1 and Athena layer.
Relays use their own funds to pay for the gas required to store transaction bundles on L1, effectively decoupling users from needing L1 accounts or L1 gas for transactions.

The storage fees for Athena transactions are paid by the relays that included them (have been assigned to each of these transactions using the random selection mechanism previously explained). The hare does deduplication and also selects for each transaction, a single relay that will get all reward and pay all the storage for that transaction.

Each relay should pay:

  1. A fee for L1 transaction itself when creating a tx bundle
  2. The cost of storing the tx in the block for each Athena tx that the relay includes.

Relays that don’t have enough L1 balance to pay for transactions are filtered out by Hare.
The payment is done after deduplication, so after the block is created, the hare participants decide how much each relay actually pays. This is due to the fact that the Hare participants are aware of which transaction belongs to which relay.

Pruning: We can prune all Athena data after a long range for example a checkpoint and have only some archival nodes to store it.

Hare dishonest majority attack

Hare participants decide how much each relay pays and gets paid, they are also in charge of the random selection. In the case of Hare dishonest majority, the worst they can do to the relay is make it pay storage fees for transactions that were included in the block but the relay did not include. This attack is very limited because relay won’t pay more than the maximum storage fee( we need to add a separate field to the bundle which says the maximum). The actual bundle will contain an extra small field which is the total storage of all the transactions that are included in the bundle (max storage cost).

We should not prune the relay signature. The reason why is: suppose relay A is included in 1 in every 50 blocks, if we don’t have signatures and there is a dishonest majority, then Hare participants can make this relay pay every block for all the transactions in the block. If the signature is there it’s only limited to blocks to which the relay actually participated so they cannot insert a relay transaction into a block where it didn’t belong and suck out money and the second thing by having this maximum storage cost, the relay is saying it will never pay more than this amount.

1 Like
2

Thanks for the summary, @Amira . Comments below…

The relays are not responsible for ensuring bundles are “coherent and executable”. They only care about ensuring that each included Athena transaction can pay the relay fee (in Athena balance)
Moreover, they don’t choose (and don’t know in advance) the order in which transactions are executed; the only guarantees for transactions in the same bundle is:

  • Atomicity: If any transaction in the bundle is included, all of the transactions are included.
  • Internal ordering: Transactions for the same account will always be executed in “Athena order”. For example if txA_1 and txA_2 are two transactions for account A, and txB_1 and txB_2 are two transactions for account B, all of which are in the same bundle, then txA_1 is guaranteed to be executed before txA_2, but it’s possible that txB_2 is executed before txA_1. (This order within an account depends on internal Athena semantics which haven’t been fully specified; it’s possible that L1 miners, for example, won’t know the internal order).

By “included in bundles”, we mean that a list of transaction IDs is included. The transactions themselves are independent objects and gossiped separately.

They also pay storage costs for the overhead the bundle itself requires (e.g., the relay signature, list of tx ids, etc.)

We should be more specific, since L1 transactions and Athena transactions are quite different in this respect.

  • Relay bundles are L1 transactions. They specify only a storage price (which determines the fee taken from the account of the relay that submitted the bundle). L1 miners “see” only the L1 bundle transaction when selecting transactions from the mempool, and don’t need to parse the associated Athena transactions (except to check their size, which determines the storage fee)

    IIRC, we haven’t finalized the storage fee mechanism, but my working assumption is that it will be some kind of second-price auction; e.g.:

    • In layer i, each Hare participant announces a minimum storage price for layer i+1. This minimum should reflect the actual cost of storage for the participant.
    • When constructing the UCB, the median storage price (out of the Hare announcements) is included in the block for layer i.
    • In layer i+1, block proposers include only transactions above the minimum set in layer i.
    • When the Hare constructs the UCB for layer i+1, they sort transactions by decreasing price, until the block is full. The storage price for all transactions in the block will be the minimal price set by an included transaction.

    The storage fee is the storage price multiplied by the size of the transaction (in “L1 gas”; for now think of this as the size in bytes, but it’s possible that there will be some extra costs related to L1 miners computational requirements, or some deductions if there’s a good way to compress the stored transaction).

  • Athena transactions don’t pay storage fees to L1 miners at all. They pay relay fees to the relay(s) that included them, in Athena funds. The payments to the relays are handled by the Athena executors. Relays have to track Athena balances to ensure that the transactions they include can actually pay the relay fees, but L1 miners have no idea (and don’t care) whether and how the relays get reimbursed for the storage fees they paid.

    This means the block must contain the association between a transaction and the relay that is responsible for it. Otherwise, if a malicious relay includes a “freeloading” Athena transaction, the executors won’t know which relay to punish.

Option 1 for storing the relay-bundle/Athena-tx association

  • The relay bundle consists of the following signed tuple: (relayid,tx_1,\dotsc,tx_n), where tx_1,\dotsc,tx_n are the Athena transactions.
  • The UCB contains all of the signed relay bundles, and a separate list of deduplicated and shuffled transaction ids (from all the relay bundles accepted to the block). Note that the Athena transaction IDs in the relay bundles can be “compressed” by storing only an index to the full deduplicated list of transaction ids.

The relay bundle overhead depends on the number of included transactions; assuming we use 20-byte IDs, 64-byte signatures and there are less than 65000 Athena transactions in a block (so 16 bits is enough for an index), the overhead would be (84 + 2*#athena-txs); if we have, say 1000 transactions in a bundle, then the bundle overhead would be 2084 bytes.

For each Athena transaction included in the block, Athena executors will pay the corresponding relays from the Athena account of that transaction. Since the executors have the full information about what which transactions were included by which relay, they can deterministically distribute the relay fees to all the relays that included a transaction. If a relay included only “good” Athena transactions, then it is guaranteed to get reimbursed for its storage fees, assuming the amount of duplication is bounded and the relay charges enough fees (relays are free to operate at a loss if they wish, of course).

Option 2 for storing the relay-bundle/Athena-tx association

This is very similar to option 1, but lets us “prune” some of the data from long-term storage; it only makes sense if the number of relay ids in a block is much smaller than the number of transactions. For example, let’s assume there are at most 256 relays and at most 65000 transactions.

  • The relay bundle consists of the following signed tuple: (relayid,H(tx_1,\dotsc,tx_n),maxL1gas), where H is a cryptographic hash function and tx_1,\dotsc,tx_n are the Athena transactions. In addition, the bundle has actual list tx_1,\dotsc,tx_n as unsigned auxiliary data.

  • The UCB contains all of the signed relay bundles, and a separate list of deduplicated and shuffled transaction ids (from all the relay bundles accepted to the block).

    For each transaction id, the UCB contains a pointer to a single relay id responsible for that transaction. This pointer can be stored as an index to the list of relay ids in the block, so would require 1 byte of storage for up to 256 relay ids in a block)

    During UCB generation, any bundle that doesn’t have some minimum number of its included transactions assigned to that relay can get filtered out entirely (since in that case it can’t be sure of covering its storage fees, even if all the included Athena transactions are good).

    Note that the USB doesn’t contain the full list of transactions associated with each relay bundle, just the hash of this list.

The L1 miners must ensure that the total L1 gas of the associated Athena transactions is less than the maxL1gas specified by the relay bundle (bundles that don’t meet this requirement can also be filtered out during UCB generation),

The relay bundle overhead here is smaller; assuming we use 20-byte IDs, 64-byte signatures and 4 bytes for max-gas, it’s about 104+#athena-txs bytes; for 1000 Athena transactions, this would be 1104 bytes (almost half the size of option 1).

For each Athena transaction included in the block, Athena executors will pay the corresponding relay from the Athena account of that transaction. Since a relay will only be assigned a subset of the transactions it included in the bundle, if a relay included only “good” Athena transactions, then it is “guaranteed” to get reimbursed for the bundle storage fees (assuming it charges enough Athena fees to cover the relay bundle overhead).

The Athena executors “blindly” trust the tx-to-relay assignment in the UCB, since they don’t have the information required to verify it. This means that in the (vanishingly rare) case of a dishonest Hare majority, honest relays can get hurt.

However, the maximum damage a dishonest Hare majority can do to an honest relay is assign it many freeloading Athena transactions (i.e., that won’t repay the relay in Athena funds), which means it can never end up paying more than the maximum gas cost it specified in the relay bundle.

Option 3 for storing the relay-bundle/Athena-tx association

This is just like option 2, except we don’t store the max-gas field in the bundle.

In this case, the overhead is a tiny bit smaller: e.g., for 1000 transactions it would be 1100 instead of 1104 bytes, but now the damage a dishonest Hare majority can do is much worse: it can essentially force an honest relay to pay an unlimited storage fee, up to the contents of its L1 balance.

I don’t think the tiny storage savings are worth the cost, in this case.

Which should we choose?

I’m ok with either option. We can start with Option 1 (which is slightly simpler and also more secure), and switch to Option 2 based on real-world transaction and bundle sizes rather than the speculative values I used here.

3 Likes
3

I agree that option 1 is the simplest one and also secure but as you said it has higher storage overhead. The overhead in option 1 is larger than the double of overhead for both option 2 and 3 which is huge in my opinion. I believe we should start directly working on option 2 instead of option 1 and then transition which includes adding the new data structure for the bundle, hashing mechanism, pointer…etc.

  • We must also modify the UCB construction logic to handle the new relay bundle format and include pointers to relay IDs.
  • Update the Athena executors to process the new UCB structure and manage relay fees.
  • upgrade miners, relays, and executors to the new option 2 and support supports both options (handle both types of bundles during transition)

I think if we believe option 2 is a good one we should work towards it directly

2 Likes
4

I’m being pedantic, but there’s a contradiction here. If relays don’t know the order in which transactions are ultimately executed, then they cannot be absolutely certain that the transactions they choose to include in a bundle will be able to pay fees.

They can, of course, use a reasonable heuristic (such as conservative balance projection) to guess with a reasonable degree of accuracy, but they cannot be certain, especially under account abstraction (there’s no guarantee that an intervening transaction won’t reduce the balance of a principal).

1 Like
5

If we assume that the relay knows and enforces the internal order of transactions within the same account (e.g., tx_A1 before tx_A2). This is akin to the nonce mechanism in Ethereum, where transactions from the same account must be processed sequentially. However, the relay does not know the order between transactions from different accounts. Then as @lane mentioned we will have a challenge for relays to guarantee atomicity for a bundle of transactions while also not knowing the exact order of execution for those transactions. This is especially true under scenarios like account abstraction, where transactions might involve complex interactions that could affect account balances in ways that are difficult to predict.
The conservative balance projection method @lane was referring to works as follows:

  • For each transaction tx in the bundle, the relay calculates the total cost of the transaction: Total Cost=Value+(Gas Limit×Gas Price)

  • The relay sets ThresholdBalance for each transaction: ThresholdBalance=Total Cost×SafetyMultiplier. The Safety Multiplier is a configurable parameter determined by the relay operator so each relay chooses their own multiplier depending on the risk they’re willing to take.

  • The relay compares the CurrentBalance of the sender account against the ThresholdBalance. If the CurrentBalance is below the ThresholdBalance, the transaction is excluded from the bundle.

  • Once the conservative balance checks are completed, the relay finalizes the bundle with only those transactions that meet the inclusion criteria.

  • Transactions that do not meet the ThresholdBalance are excluded and either returned to the mempool or discarded.

I haven’t found any projects using this method though “conservative balance projection”. I found however the Perceived Transaction Likelihood of Success method used Solana to optimize transaction inclusion and minimize the risk of transaction failures. The Solana method evaluates a broader range of factors beyond just balance, such as resource usage and network conditions whereas the Conservative Balance projection method is more focused on ensuring that a sender’s balance is well above the required fees.

1 Like
6

A special algorithm, called the Elliptic Curve Verifiable Random Function (ECVRF), is used to select smeshers randomly for each Hare round. We can use the same protocol to randomly assign transactions to relays.

Random Selection Process

  • All relays register their participation in the transaction assignment process. This ensures that only active and willing relays are considered for assignment.

  • Each relay is identified by a unique identifier (smesher ID) and a corresponding elliptic curve key pair (private key and public key).

  • Input Construction for ECVRF:
    1. Smesher ID
    2. Transaction ID: The unique identifier of the transaction that needs to be assigned.

  • Each relay constructs the input to the ECVRF
    Input = Hash(Smesher ID || tx_id)

  • Each relay uses its private key and the constructed input to generate the ECVRF output:
    ECVRF Output=ECVRF(Private Key, Input)

  • The output is deterministic and also verifiable.

  • Signature Comparison: All participating relays calculate their ECVRF output for the given transaction ID. The relay with the lowest ECVRF output is selected to handle the transaction. This process is repeated for each transaction that needs to be assigned.

1 Like
7

Each transaction is assigned to exactly one relay based on the lowest ECVRF output. This ensures that no two relays are responsible for the same transaction, which inherently prevents duplication at the relay level. Is there a possibility transaction assignment isn’t unique using this method @talm?

As for deduplication pre-assignment, each transaction is assigned a unique identifier known as the Transaction ID. For each transaction added to the relay mempool, each transaction’s ID is checked against existing IDs. If a new transaction has an ID that matches an existing transaction, it is flagged as a duplicate.

1 Like
8

Relays should certainly use a conservative-balance heursitic. They can’t be certain about payment, but they can decide on their risk level – they keep track of the mempool and the current state, so they can estimate how “close to the edge” the account is in terms of payment ability.

It is true that an adversarial relay that is cooperating with a malicious user (or playing the role of both) could potentially include many Athena transactions in the relay bundle that collectively drain the corresponding Athena account, and thus make it more likely that an honest relay will include a transaction without getting paid for it (since the honest relay doesn’t see the adversarial bundles before creating their own).

We can deal with this type of attack in two ways:

  1. Do nothing — we let the “invisible hand” of the market solve it. Relays will develop their own techniques for mitigation that don’t rely on protocol-level support. This is great if it works, but there’s a risk that relays won’t be able to find such techniques, so the relay fees will have to be high to cover the potential losses.
  2. Add protocol support to help relays. Here are two ideas (I haven’t thought them all the way through, so they might be broken in various ways):
    • Give relay fees priority over transaction execution. I.e., when executing a block, we first go over all transactions in the block and deduct relay fees from the accounts, and only then make a second run over the transactions and execute them. This doesn’t completely solve the problem, since a malicious account can add a transaction that has a very large relay fee, and drains the account before the other transactions have their fees deducted. But maybe we can combine this with an additional ordering heuristic – such as taking the smallest fees first – which would make it much harder to execute this kind of attack, or at least limit its damage.
    • Require a minimum duplication level. If the Hare only accepts transactions that appeared in a sufficient number of relay bundles, it will become much harder to hide a transaction from honest relays — in order to do so, you’d have to have a big enough coalition of malicious relays to ensure the hidden bad transactions get in.
1 Like
9

I don’t think there’s a reason to use a VRF here – we don’t need verifiability, since we have an honest majority in the Hare (if there isn’t an honest majority, they can do much worse things than assign transactions non-randomly).

VRF evaluations and verifications have a relatively high cost (requiring an elliptic curve operation), so if we don’t need them it’s better not to use them.

1 Like
10

The “hidden transactions” attack is not at all specific to Spacemesh. It could happen on Ethereum or another chain today via “dark mempools.” We should look into adversarial MEV, mempool attacks, and what other chains including Eth are doing about it, if anything. Here is one recent paper on the topic, I’m sure there are others:

This is a nice idea. It could also have the effect of making “dark MEV pools” harder to pull off. Again, I think we should evaluate it in the broader context of MEV.

1 Like
11

Ethereum (without account abstraction) maintains the invariant that a transaction can only reduce the ETH balance of the initiator’s EOA. This makes mempool management much easier for the reason @Amira cites: as long as a node knows the order of transactions from an EOA, which it does because of the nonce–which in Ethereum must be sequential, so transactions cannot be “hidden”–then it knows which ones will be able to pay gas.

We may want to maintain the same invariant in Athena to begin: ensure that a transaction can only reduce its principal’s SMH balance. We may also want to enforce sequential nonces, to begin, to avoid the “hidden transaction” attack. We can look at relaxing these constraints later.

2 Likes
12

I think the attack we’re describing here is worse, since it attacks the chain infrastructure rather than other transactions, and can make attacked relays lose money, since they “prepay” storage fees at L1, and only when the transactions are executed get reimbursed in Athena funds. This makes it more reasonable to provide infrastucture-level support for mitigating the attack.

I agree that we should look at how other chains solve/mitigate this issue, since the problems are very similar.

Allowing transactions to reduce only their principal’s balance sounds like it could be helpful. If we prioritize relay fees, it might be enough to restrict this only for relay fee payment, since once the relay fee is paid, we don’t care if the transaction fails due to the account owner’s own actions (i.e., users can still shoot themselves in the foot, but they can’t shoot the service providers).

I think we really don’t want to require sequential nonces, since that would conflict with both the parallel collection of transactions, and with the account abstraction where different users want to concurrently generate transactions for the same principal.

It also doesn’t really solve the problem, since the “dark” transaction can just replace a “transparent” transaction with the same nonce.

Come to think of it, the nonce issue is an attack in itself, unless Hare participants can filter out duplicate nonces:

  • a malicious sender can create a “good” transaction that pays relay fees
  • honest relays include this transaction in their bundles, paying for its storage
  • a malicious relay includes a “bad” transaction with a conflicting nonce (this could also pay fees, but since it’s included only by the malicious relay, only that relay would benefit)
  • If the bad transaction ends up first in the block, then the good transaction doesn’t pay fees.

This seems to me a pretty good argument for having a concrete nonce scheme that is easily parseable by L1 miners; this way the Hare would filter out the transactions that don’t pay due to nonce conflicts, so honest relays wouldn’t pay storage fees on these transactions.

Here’s an idea that might help solve the problem completely (in combination with the ideas above):

  • every relayed tx includes a “max relay fee” field.
  • relays include a “current balance” hint for each principal in their bundle. This indicates what they are using as the conservative balance.
  • during UCB construction, after transactions are ordered, for each principal separately:
    • the Hare miners compute the cumulative sum of max relay fees
    • when this sum passes the current balance for a relay that included that transaction, the transaction is removed from that relay’s transactions (i.e., it won’t pay for its storage, but also won’t be eligible for its fees).
    • If the transaction is removed from all relay bundles, it is dropped from the block.

The current balance hints don’t need to be stored in the block

Example:

There are txs A, B, C, D each with a max relay fee of 1 (all from the same principal X).

  • Relay 1 hints that the current balance of X is 3 and includes txs A, B, D.
  • Relay 2 hints that the current balance of X is 2 and includes txs A, C
  • Relay 3 hints that the current balance of X is 3 and includes tx C

During UCB construction, the transactions are ordered A,B,C,D. In this case,

  • A can be assigned to Relay 1 or 2
  • B can be assigned only to Relay 1 (that’s the only relay that included it in its bundle)
  • C can be assigned only to Relay 3 (it can’t be assigned to Relay 2 because the cumulative max fee by the time we get to C is 3, and Relay 2 hinted that the balance was 2)
  • D can’t be assigned to any relay, so is dropped from the block.
2 Likes
13

i think it would be hard for a malicious relay to choose transactions from same account for the purpose of draining the associated Athena account and basically have other honest relays risking of not being paid if we do apply a random transaction assignment to relays. This means relays don’t choose which transactions are being assigned to them, what they can choose is whether to include them or not in their bundle.

1 Like
14

If we do require a minimum duplication level then we’re back to the problem of whether transaction fees are shared between these relays that included the transaction in their bundle or not (who pays storage cost?). We’ll also be increasing the storage burden where each transaction is linked to several relays instead of one.

1 Like
15

No, it’s easy, because the transactions are only randomly assigned to relays that include them. Since the malicious transaction only appears in one relay, it will definitely get assigned to that relay.

But even if this were not the case, it just makes the attack a bit more expensive for the adversary — as long as the bad transaction is included in the block before honest transactions, the honest relays won’t get paid.

There’s going to be duplication anyway for most honest transactions. And the question of whether we split the costs (and the fees) evenly between relays that included a transaction or randomly assign a single relay to each transaction is orthogonal.

1 Like
16

I definetely like this idea of having the Hare filter out conflicting nonces. I guess left to define what that scheme is.

So basically, instead of using a sequential nonce for ordering, the transactions are ordered based on a combination of factors, including the relay fees, the current balance hints provided by relays. As transactions are ordered, the cumulative relay fees are calculated and compared against the balance hints provided by relays. This ensures that as soon as the cumulative fees exceed the available balance, no further transactions from that principal are included. This effectively prioritizes the relay fees because transactions that cannot pay the required fees are filtered out.

False Balance Attack:

A malicious relay could provide a false or overly optimistic balance hint, suggesting that a principal has more funds available than it actually does. This might lead honest relays to include transactions that, in reality, cannot be paid due to insufficient balance. If we apply this to the previous example with transactions A,B,C,D from principal X.

  • Principal X has four transactions: A, B, C, D.
  • Each transaction has a max relay fee of 1 unit.

Assume the true balance of principal X is 2 units, but Relay 1(malicious) falsely claims that the balance is 3 units.

Attack Execution:

  • Relay 1 includes transactions A, B, and D in its bundle, relying on the falsely reported balance to ensure that these transactions are considered for inclusion.

  • Relay 2 correctly hints that X’s balance is 2 units and includes transactions A and C in its bundle.

  • Relay 3, unaware of the false hint, hints that X’s balance is 3 units based on earlier assumptions or incorrect data and includes transaction C in its bundle.

  • Cumulative Fee Calculation:

    • The UCB construction process starts by ordering the transactions: A, B, C, D.
    • Transaction A is first. The cumulative fee so far is 1 unit, and A can be assigned to either Relay 1 or Relay 2.
    • Transaction B is next. The cumulative fee is now 2 units. Since Relay 1 falsely claimed that X has 3 units, B can be included (but in reality, there isn’t enough balance to pay for B after A).
    • Transaction C is then considered. The cumulative fee is now 3 units. Relay 2, which correctly hinted a balance of 2 units, cannot include C. However, Relay 3, thinking X has 3 units based on an outdated or incorrect assumption, includes C.
    • Transaction D is dropped because, even with the false hint, the cumulative fee has already reached or exceeded the falsely reported balance.

  • Actual Payment:

    • In reality, after A (1 unit) is paid, only 1 unit remains in X’s balance.
    • B should not have been included, but because of the false hint from Relay 1, B was included in the UCB.
    • When processing, C finds that only 1 unit remains, not enough to cover its fee, leading to a failure or rejection of the transaction. Relay 3, which included C based on a false assumption, ends up not getting paid.
1 Like