# Aurora sharding

While NEAR scales horizontally with sharding, Aurora doesn't since it works as a single contract on ONE shard. This notes explore the possibillity of improving aurora performance by deploying multiple versions of itself in separate shards.

## Chain Id

Having multiple silos means that each silos must have a way to identify itself in order to avoid replay transactions on different silos. [Chain id](https://ethereum.stackexchange.com/a/37571/45323) are used for this end; each Ethereum-like network uses a [unique chain id](https://chainlist.org/).

[Aurora uses](https://doc.aurora.dev/getting-started/network-endpoints/) `1313161554` (`0x4e454152`) for mainnet.

### Different chain id

Use a different chain id per silo.

#### Pros

- Simple
- Relayer can route easily to proper silo
- Supports custom features from any wallet.

#### Cons

- Users needs to check as trusted multiple aurora networks (this happens on metamask, is very tedious, and may be a potential vector of attack).
- Potential collision with other networks using the same chain id. (See more on [factory section](#)).

### Chain Id on Data

Establish a new standard on `tx.data` (`tx.input`) that has no collission with any legit message. Idea being that `aurora_target` is specified as part of the data, together with the actual data itself.

:::spoiler Preliminiary proposal
1. [4 bytes of 0] `0x00000000`
2. [1 byte] `0xff`
4. [8 bytes] chain_id
5. rlp_encoding of the actual data.

Note that 5th byte will never be `0xff` since it would imply that the underlying rlp data would be larger than what it is possible to handle in a reasonable universe.
:::

#### Pros

- Relayer can route easily to proper silo
- There is only on chain_id being used for all txs targetting aurora.

#### Cons

- Custom features from wallets wont' be available outside of the main silo. I.e. FT && NFT features such as query, transfer (and interact).
- Developers working on Aurora silos need to craft their own transactions "manually". We may provide a library in js (and other languages) to help them craft their txs.

### Chain Id on Address

Encode the `aurora_target` on the address of the target contract. (For examlpe in the last 4 bytes).

#### Pros

- Relayer can route easily to proper silo
- Supports custom features from any wallet

#### Cons

- What to do with EOA?
- What to do with CREATE2?
- If there is any conflict with main silo what to do (should we have a main silo at all?)

## Cross contract calls

[Discussion](https://github.com/aurora-is-near/aurora-engine/discussions/291)

Add precompile that allows scheduling a cross contract call to an arbitrary NEAR contract with arbitrary arguments. This call is scheduled through a secure intermediate contract, to avoid calling contracts using `aurora` as `predecessor_account_id`.

class AuroraEngine:
    # Use an acount id that implements `Aurora Gate`
    GateAccountId = 'gate.aurora'
    
    def cross_contract_call_precompile(self, 
                    target: AccountId, 
                    method: str, 
                    args: bytes,
                    # Format used to append sender address to the args.       
                    append_sender: Union[None, Json, Borsh]):
        
        GateAccountId.schedule_call(
            target,
            method,
            args,
            # Sender is used from the current address calling this precompile
            self.sender,
            append_sender
        )
        
class AuroraGate:
  def schedule_call(self, 
                    target: AccountId, 
                    method: str, 
                    args: bytes,
                    sender: Address,
                    append_sender: Union[None, Json, Borsh]):
    
    # Create contract call roughly as:
    target.method(args || sender) 

## Silos composability

Silos may talk between each other using `AuroraGate` interface.

## Native token

It only make sense to have ETH in a single aurora account! Other silos may have different behavior:

- No Token at all
- Different "native" token exposed as NEP-141 to NEAR

**Decision**

- Native token will be ETH for each silo (for now)
- Remove NEP-141 inteface from non-main silo

## Native connectors

Re-implement native connectors using `AuroraGate` interface. Currently there are some precompiles that works as a bridge for ERC20 between NEAR an Aurora. This won't be required anymore, and the new interface should allow creating connectors for NFT, FT and more.

Remove old precompiles if they are not being used by any other contract on Aurora. **TODO:** Investigate if exit precompiles have been used by any contract which is not the one bultin in house.

## Factory

Create `factory.aurora` that allows (everyone? authorized users?) deploy their own aurora silo.

### Upgrading

Silos should support getting safe upgrades coming from the factory by calling a single function that pulls the new binary.

Question: If there is a security vulnerability that affects all silos (how to make sure all of them get upgraded properly?).

## Indexer / Explorer

Each silo must be properly indexed so every transaction is displayed on the explorer. Ideally this should happen on a single explorer instance but it might have problem if some address collide between different silos.

## Starting block number

- The same as NEAR Blocks
- Start from 0

## Genesis (Bootstrap) state

- Initialize in chunks.

## ERC20 Contract address consistency

- Keep contract addresses already deployed on the main silo. Pass it genesis file.
- New `deploy_erc20` workflow, it is deployed on behalf of the nep141 (security considerations)

## Endpoints URLs

- proximity.aurora.dev
- proximity.mainnet.aurora.dev