1. Add two jsonrpc for geode. Both functions have no params.

   1. attestor_list() -> Vec<(Vec<u8>, Vec<u8>)> Return the registered attestors' “url” and “pubkey” by vector

   2. registered_geodes() -> Vec<Geodes> Return the registered(not attested) geodes' record by vector

2. Set time limit to u64::max_value() in case that geode which registered but can't get enough attestors at limited blocks will be deleted. This is because we need a long time runing geode which is registered but not attested currently.

Changes inclued in this PR:

1. Add transfer pallet, support 2 kinds of extrinsics: transfer_to_evm_account(signed extrinsic), transfer_from_evm_account(unsigned extrinsic)

pub fn transfer_to_evm_account(
            origin: OriginFor<T>,
            target_address: H160,
            value: BalanceOf<T>,
        ) -> DispatchResultWithPostInfo
// message: source account address(H160, 0-19 bytes), target account address(AccountId32, 20-51 bytes), amount(u128, 52-67 bytes), nonce(u32, 68-71 bytes)
// signature: 65 bytes
pub fn transfer_from_evm_account(
            _origin: OriginFor<T>,
            message: [u8; 72],
            signature_raw_bytes: [u8; 65]
        ) -> DispatchResultWithPostInfo

2. Add 2 rpc methods, in transfer_to_substrate_account, will check balance, nonce, recovered signer and make sure params are legal hex string with specified length. If all checks pass, will submit a unsigned extrinsic transfer_from_evm_account

#[rpc(name = "transfer_to_substrate_account")]
    fn transfer_to_substrate_account(
        &self, 
        message: String,
        signature: String
    ) -> Result<u64>;

    #[rpc(name = "transfer_nonce")]
    fn transfer_nonce(
        &self,
        evm_addr: String
    ) -> Result<u32>;

We can use subkey to generate a sr25519 key pair, we will get the Secret Seed and Account ID, Account ID is the substrate address(let us call it as addressA), and you can genarate the private key using this secret seed. Besides, we can import the generated private key into Metamask and get a corresponding evm address(call it addressB), but actually these 2 addresses are address of 2 different account. We can do a experimentation:

1. using the evm address we get above to get 10 testnet ATA from faucet
2. import the substrate address into blockchain explorer
3. get balance of the imported account in step#2(Developer -> Chain state -> system -> account) We will find tha balance of the imported account is not 10, actually is 0 if it is a new generated account

Then you can use code below to calculate a substrate address from the evm address, <evm address> is the address in Metamask without leading 0x

use blake2::VarBlake2b;
use blake2::digest::{Update, VariableOutput};
use hex;

fn main() {
    // create a Blake2b object
    let mut hasher = VarBlake2b::new(32).unwrap();

    // write input message
    let mut data = [0_u8; 24];
    data[0..4].copy_from_slice(b"evm:");
    data[4..24].copy_from_slice(&hex::decode("<evm address>").unwrap());

    hasher.update(&data);

    // read hash digest and consume hasher
    let _res = hasher.finalize_variable(|res| {
        println!("{:?}", hex::encode(&res[..]));
    });
}

you will get a string like 65f5fbd10250447019bb8b9e06f6918d033b2feb6478470137b1a552656e2911 by running code above, then come back to blockchain explorer, paste the string here(we will get a another address, call it addressC ) and call account function: you will find that balance of this account is 10 ATA(or 10 BATA) The result verifies that actually addressA and addressB are 2 different account in our chain, addressB and addressC are same account in our chain. Currently, assume that someone have some ata in his evm address account, and he want to interact(send extrinsics) with our chain, it is impossible because he doesn't know the private key of corresponding substrate address. So maybe we need to change the mapping methods in evm pallet, take the previous example, we should mapping addressA to addressB

Fix the memory leak. It is caused by crate "thread_local" and the crate fix the BUG at "1.1.3". You can just run "cargo update -p thread_local" or update the repository. Just ensure the version of "thread_local" in your cargo.lock is "1.1.3".

Talk about memory leak in substrate: discussion Fix at substrate: fix cargo.lock Fix at thread_local: drop the value

Use "aura" consensus algoritm instead of "babe" for development test. Here are some points:

1. Every session contains 10 blocks which can be changed in runtime.

2. There are three mode to run: "dev", "local" and "staging". "dev" is a single node mode and please run the command: "./target/release/automata purge-chain --dev -y" before you run: "./target/release/automata --dev".

   "local" mode needs two validators and "staging" needs four validators.

Now start the development network using the BABE algorithm.If there is only a single node, the network will not function properly after being shut down for a period of time, which is not conducive to internal testing.

So it makes more sense to change the BABE algorithm to the AURA algorithm.

The error message:

ClientImport("Unexpected epoch change")  

This patch enables the automata node to accept subscriptions for the state of a geode via the "geode_subscribeState" RPC method.

The subscription mechanism is implemented by getting storage updates: the subscribe method creates a stream over which it receives notifications when the storage value of the geode is updated; the storage value is converted to a GeodeState that is sent to the Subscriber.

1. Need to check if the instance exist before using it (will not record issues in fulfillment pallet, since this pallet will be removed) After the block has been initialized, each valid extrinsic is executed in order of transaction priority. Extrinsics must not cause a panic in the runtime logic or else the system becomes vulnerable to attacks where users can trigger computational execution without any punishment. --Substrate Developer Hub https://github.com/automata-network/automata/blob/3b11d5502f66908a190f02613e630caac80f0a4c/pallets/attestor/src/lib.rs#L218-L219

There is a corner case that could cause the chain having dirty data:

If an attestor get disconnected from chain, and not going to come back, the geode that it was attesting will remain in Registered state forever, and no one would be responsible for checking the liveness of that geode to ensure it's in proper status.

Thus here are some TODOs for eliminate this corner case:

1. Attestor should maintain a way of informing the chain about its status periodically, if it failed to do so in a timeout, the chain should mark it as an offline attestor.
2. As geode needs to be attested by a certain amount of attestors to get its state changed into attested(currently the amount is 1), while attestor could be offline at any moment, the geode needs a way to keep themselves aware of the situation on chain, and try to find new attestor as soon as possible to meet required number of attestors, otherwise it could be marked as degraded, or even worse: if no attestor is attesting it, will be marked as unknown.
3. While it's true that geode can poll the chain to gets the information from chain, it would definitely be more ideal if the Geode can subscribe the Event emitted from the chain.

Hi, I conduct build process according to instaction I have installed docker and docker-compose

I have this problem:

a@s:~/progs/automata$ sudo ./scripts/run-network.sh
[sudo] hasło użytkownika adi: 
Running the network
Image: automata
Chain: local
Pulling validator-a (automata:)...
ERROR: The image for the service you're trying to recreate has been removed. If you continue, volume data could be lost. Consider backing up your data before continuing.

Continue with the new image? [yN]y
Pulling validator-a (automata:)...
ERROR: pull access denied for automata, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
a@s:~/progs/automata$ ./scripts/run-network.sh
Running the network
Image: automata
Chain: local
ERROR: Couldn't connect to Docker daemon at http+docker://localhost - is it running?

If it's at a non-standard location, specify the URL with the DOCKER_HOST environment variable.
a@s:~/progs/automata$ 

How I can make automata running?

pi@pi4:~/automata $ cargo build --release Compiling sct v0.6.0 Compiling webpki v0.21.4 Compiling wasm-timer v0.2.5 Compiling rw-stream-sink v0.2.1 Compiling soketto v0.4.2 Compiling yamux v0.8.1 Compiling libp2p-pnet v0.20.0 Compiling intervalier v0.4.0 Compiling futures-diagnose v1.0.1 Compiling exit-future v0.2.0 Compiling prost-build v0.7.0 error: failed to run custom build command for prost-build v0.7.0

Caused by: process didn't exit successfully: /home/pi/automata/target/release/build/prost-build-0f2fe0256215a37a/build-script-build (exit code: 101) --- stderr thread 'main' panicked at 'Failed to find the protoc binary. The PROTOC environment variable is not set, there is no bundled protoc for this platform, and protoc is not in the PATH', /home/pi/.cargo/registry/src/github.com-1285ae84e5963aae/prost-build-0.7.0/build.rs:100:10 note: run with RUST_BACKTRACE=1 environment variable to display a backtrace warning: build failed, waiting for other jobs to finish... error: build failed pi@pi4:~/automata $