# Scaled (quasi-rollup mode )

Consider that there's an on-chain contract that maintains a sequence of updates to accounts state (account_obj = owner's address + balance). Accounts state is represented by the root of a sparse markle tree (referred to as `account tree`). To add an account_obj to account tree, you first calculate path (path = keccack256(account_obj.address)) and concatenate it with account_obj and store it at `path` in the account tree.

Now consider that user A, B, C, D, E have accounts in the account tree. Moreover B maintains receipts with A, C, D. Receipts are between two users and are latest record of how much each of them owe the other. For example B's receipt with A would look something like -

{
    A_address: 0xABC,
    B_address: 0xBCD,
    A_owes: 10000,
    B_owes: 120,
    expires_by: 12901391 (timestamp)
}

For a receipt to be valid both users between which the receipt is maintained should sign it. A receipt can be updated with new values by updating "expires_by" timestamp to some later time than the previous one. Thus, a valid receipt is the one to which both users have agreed as latest (i.e. both have signed & there exists no other receipt with a later "expires_by").

User B can settle the owed amounts on receipts by updating accounts in account tree on-chain. To do so B does the following -
1. Retrieves latest state of account tree (latest_root).
2. Builds updates_arr where each receipt corresponds to a single sequence of minor updates to account tree.

For each receipt -
User B generates a tuple of (TU, sigTU), where TU consists of updates to account tree caused by receipt and sigTu is B's signature on TU. TU is a tuple of form (root_before, root_after, receipt), where root_after is root of account tree after applying updates to respective account_objs, according to the receipt, to root_before.

For example, take the receipt shown above -
Consider B_old & A_old as B's & A's existing account_objs. The update should change (1) B_old -> B_updated where B_updated.balance = B_old.balance + A_owes - B_owes and (2) A_old -> A_updated where A_updated.balance = A_old.balance + B_owes - A_owes.
User B first derives B_updatd and A_updated then does the following -
* Updates leaf corresponding to A's account_obj in account tree from A_old to A_updated.
* Updates leaf corresponding to B's account_obj in account tree from B_old to B_updated
* Calculates new of root (root_after) of account tree.

B then generates TU = (root_before, root_after, receipt) and signs it to generate sigTU. B then appends (TU, sigTU) to updates_arr.

Note that root_before of element at index `i` is equal to root_after of element at index `i-1` in updates_arr and root_before at index 0 is equal to latest_root retrieved in step 1.

In the end User B has updates_arr that transitions account tree from latest_root to root_after of last element in updates_arr. root_after of last element in updates_arr will become the latest_root when posted on-chain and will be finalised after challenge period.

3. Posts the updates_arr on-chain.

After user B posts updates on-chain there's a challenge period of few days during which anyone can post a proof that proves updates posted by B are invalid. Like optimistic rollups if no challeges are received during challenge period, the update will be finalised.

Challenges can be of following types -
1. Invalid receipt - User B posted invalid receipt in the update (i.e. receipt with invalid signatures OR "expires_by" smaller than block.timestamp).
Challenger can submit the update (i.e. (TU, sigTU)) that contains the invalid receipt on-chain. The contract will check (1) B attested to update (i.e. valid sigTU) (2) Signatures do not match respective users (i.e. A and B for receipt between A & B) and slash user B.
2. Invalid state update - User B posted invalid state update (i.e. when account_objs are updated according to receipt in root_before, the reesult root does not match root_after).

To prove, challenger prepares the following evidences & posts them on-chain (taking example receipt as a case) -
* A_old & B_old account objects (i.e. before update).
* B's invalid state update (i.e. (TU, sigTU)).
* Witness data {w1, w2} - Challenger provides inclusion proof A_old (w1) in root_before. Updates root_before to intermediary_state_1 by updating A_old to A_updated. Provides inclusion proof B_old (w2) in intermediary_state_1.

Contract does the following in the given sequence -
* Derives A_updated, B_updated from A_old, B_old using receipt in B's state update.
* Verifies w1 in root_before
* Updates A_old to A_updated using w1, thus deriving intermediary_state_1.
* Verifies w2 in intermediary_state_1.
* Updates B_old to B_updated, thus deriving *correct* root_after.
* If *correct* root_after does not matches root_after in TU posted by B, then B is slashed.

There exist few additional cases through which users can cheat
1. User owes more than their account balance in account tree (i.e. User A owes more than their balance when all their receipts are aggregated) - To disincentivise such behaviour, as long as receipt is valid, update can cause account balance to go negative. Plus, if account balance goes from + to - in the update, the amount can be amplified by some factor (ex. 2x) to cause penalty.

The dishonest user cannot try to withdraw right after owing more than they their account could afford and before the other user could post updates on-chain, since a withdraw state update isn't valid until after all receipts have expired. So the other user, whom dishonest user was trying to cheat, can produce not expired receipts on-chain to slash dishonest user.

2. Dishonest user posted updates on-chain, but did not include latest receipt for an update - The other user with the latest receipt (i.e. receipt of which "expires_by" is greater than the "expires_by" of receipt included in the update) can produce the latest receipt on-chain to cause slashing to dishonest user.

#### Note on data size

1. Updates:
Size of Receipt: (32 bytes * 2 + 8 bytes * 2 + 4 bytes) = 84 bytes
Size of TU: 32 bytes + 84 bytes + 32 bytes = 148 bytes
Size of updates_arr = 148 bytes * no_of_receipts
2. Invalid update challenge:
Number of accounts = N
Account size = 32 bytes + 8 bytes = 40 bytes
Single merkle proof size = 32 + (32 * log(N)) bytes.
Total Size of {w1, w2} = 2 * (32 + (32 * log(N))) bytes
Total evidence size = 148 bytes + 2 * (32 + (32 * log(N))) bytes + 2 * 40 bytes.

### Extra
[In progress doc that tries to get into detailed specification can be found here](https://hackmd.io/n3jdcFSoQU-zmZMxgjx5Hg)