---
# System prepended metadata

title: Interview notes

---

# Interview notes

## Ethereum interview

Ethereum interview


Let’s discuss about this issue: https://github.com/near/rainbow-bridge/issues/557

How is the state represented in Ethereum.
How to access arbitrary places in the state.
How to modify arbitrary places in the state. (sStore function)
How to build proofs about arbitrary elements of the state.

## Blockchain interoperability interview

Blockchain Interoperability Interview Questions:

Interview:
    Level 0: There is oracle that returns a value. You need to provide a way to query such oracle from NEAR.
    Level 1: How to query historical data from NEAR.
    Level 2: Implement god mode upgradability.
    Level 3: Implement multi-sig upgradability.
    Level 5: Storage is expensive, how to optimize it.


## Relayer interview

Relayers Interview:


struct Block {
    hash: CryptoHash,
    height: u64,
    //...
}

// Ethereum RPC
fn get_ethereum_block(height: u64) -> Block;

fn get_last_ethereum_block() -> Block;

// Near RPC
fn get_last_ethereum_block_on_near() -> Block

fn submit_ethereum_block_on_near(block: Block)

// Second iteration

fn submit_ethereum_block_in_batch_on_near(blocks: Block[])


1. Write a tool that start reading blocks from one blockchain and relaying to the other
    - You need to ask about time between blocks.
    - RPC load

2. How would you host it from a dev-ops perspective. How to monitor, and set alerts.

3. Update the chain in case of a fork

4. What if the chain is too deep, how can we speed up this process (keep the relayer state-less)

5. We can submit several blocks at once, but we can only know and estimate of the amount of gas. 


——

1.  Write a program that reads information from one blockchain to the other blockchain
    Use a mocked blockchain

    Block;
        hash
        height

    get_ethereum_block(height: Int) -> Block

    get_last_ethereum_block() -> Block

    get_last_ethereum_block_on_near() -> Block

    submit_ethereum_block_on_near(block: Block)

    submit_ethereum_block_in_batch_on_near(blocks: Block[])
    ----

    [Subquestion] Check for experience with:
        - ethereum
        - near
        - rust
        - javascript
        - typescript

?? From a devops perspective, how

2. How to handle (submit_ethereum_block_on_near) if it timeout.
    Need to resubmit, take into account the cost.

- How to monitor this process, and react to errors?

3. Update the chain in case of fork.
    
    Some times in ethereum the chain forks in two different chains. We need to find the first common element, and update all blocks starting from it.

4. Use binary search to achieve this.

5. Submit several blocks at once. What happens if the gas limit is too low. If it fails need to adapt the number of blocks passed.

6. Serialize, and deserialize, Blocks messages.

* Find the first common block.
* Query the new height, and submit it.
* Do binary search to improve this speed.


* How to use adaptive gas.
Run binary search to find the proper height.
* Upload the height and the