search

circle-free / optimistic-roll-in

Layer-Agnostic Optimistic Roll-Ins For Isolated-State-Transitions - A Proof of Concept
MIT License
1 stars 1 forks source link

Balances clarification #23

Open rogercoll opened 3 years ago

rogercoll commented 3 years ago

Hi,

I was checking your code regarding the smart contracts part and I would like to clarify an important aspect to fully understand it.

In the optimistic-roll-in implementation smart contract (opritmistic-roll-in.sol) there are different maps in order to maintain the state and balances the participants, indeed the following two:

  mapping(address => bytes32) public account_states;
  mapping(address => uint256) public balances;

Could you provide more information on what is stored in each of them? The balances one seems to handle the amount of ethers of each key (address) but I am not able to see where the balance amount is updated.

In addition, does the actual merkle tree root state saved in the smart contract?

Finally, when calling the initialize() function that calls the initialize_state() function of the some-logic-contract.sol the deposited ethers are not saved in the account_states, neither the balances map. What happens with this deposit?

Best regards,

deluca-mike commented 3 years ago

@rogercoll So sorry I didn't see this earlier. My bad.

Could you provide more information on what is stored in each of them?

balances holds the bonded and accrued ETH of each participant, which can be slashed if they are proven fraudulent, and accumulates when they prove someone else fraudulent. account_states is the state hash for each account, which includes the calldata merkle root, current state, and last time.

does the actual merkle tree root state saved in the smart contract?

First, see https://github.com/circle-free/bouncy for a better example of usage (however, slightly outdated). As for the question, as per above, the merkle root is hashed with the current state and last time and stored as the value in the account_states, keyed to that account. There is no need for the underlying logic contract to store user state, as it is stored here and always passed in as an argument to the logic contract's functions.

As for the sent ETH when calling initialize, the contact applies the minimum necessary as a bond, which does get saved as part of the user's balance, and forwards the remainder, if any, to the logic contract. This allow the logic contract to make decisions based on how much it is receiving after the bond amount is taken into account.