EVM Subdomains

[Joshua2Mars]

1. we need subdomains(faucet, API, explorer, Bridge) for testnet and subdomains(API, explorer, Bridge) for mainnet

Testnet: faucet.eosnetwork.com/ api-testnet.eosnetwork.com/ explorer-testnet.eosnetwork.com/bridge-testnet.eosnetwork.com

mainnet: api-evm.eosnetwork.com/ explorer-evm.eosnetwork.com/bridge-evm.eosnetwork.com

2. we will configure CDN acceleration, load balancing, and other measures for certain functional pages, so please give us some guide

[kj4ezj]

From IM, I think EVM mainnet stuff should be under a sub-domain...

api.evm.eosnetwork.com
bridge.evm.eosnetwork.com
explorer.evm.eosnetwork.com

...as well as the EVM testnet domains.

api.testnet.evm.eosnetwork.com
bridge.testnet.evm.eosnetwork.com
explorer.testnet.evm.eosnetwork.com
faucet.testnet.evm.eosnetwork.com

This gives us more flexibility.

For example, the entire *.testnet.evm.eosnetwork.com. or even *.evm.eosnetwork.com. could point to entirely different cloud infrastructure, enabling your team to manage EVM subdomains in a self-service manner, if you want to. I am also happy to manage them as long as you need, but it gives us more flexibility in the future. This could point to another AWS account, another AWS org, GCP, Cloudflare...whatever, it doesn't matter and no changes you could make could damage other *.eosnetwork.com. domains.

[kj4ezj]

Duplicated by eos-evm issue 404.

[kj4ezj]

Closing Summary

This task ended up expanding substantially in scope from "just DNS" to implementing all of the networking infrastructure, end-to-end.

All endpoints are up! Links and implementation details are in the sections below.

There is still a lot of room for improvement. The purpose of this task was to achieve a minimum viable product (MVP) for testnet and mainnet launch, and this has been accomplished! Yay! As such, I am closing this ticket. We will track work beyond an MVP in subsequent tickets. I will link them to this issue.

Key Dates

Key dates relevant to this ticket, in US Eastern daylight timezone (EDT).

1. 2023-03-23 - First stakeholder meeting between ENF Automation and EVM team late Thursday night.
2. 2023-03-27 - EOS-EVM testnet public launch on Monday.
3. 2023-03-29 - All stakeholders ratify proposed domain name schema.
4. 2023-03-29 - Testnet endpoint infrastructure delivered to customer and stakeholders.
5. 2023-04-03 - ENF accepts EOS Nation testnet faucet implementation.
6. 2023-04-03 - Faucet endpoint using EOS Nation implementation delivered to customer and stakeholders.
7. 2023-04-03 - New mainnet AWS account authorized Monday night.
8. 2023-04-04 - Mainnet AWS account delivered to customer Tuesday night.
9. 2023-04-05 - Customer gains access to mainnet AWS account Wednesday morning.
10. 2023-04-07 - Mainnet endpoint infrastructure delivered to customer Friday night.
11. 2023-04-13 - EOS-EVM mainnet public launch on Thursday.

Testnet

Endpoints and end-to-end network infrastructure were up for all four testnet resources on 2023-03-29.

On 2023-04-03, the ENF accepted a generous offer from @DenisCarriere at EOS Nation to use a faucet they created. I pointed the faucet subdomain to their infrastructure per direction from leadership that afternoon. The source code lives here.

• api.testnet.evm.eosnetwork.com
  • Connect with MetaMask
  • Example using curl to get EOS-EVM testnet block height:

    curl -fsSL 'https://api.testnet.evm.eosnetwork.com/v3' -X POST -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' | jq .

• bridge.testnet.evm.eosnetwork.com
• explorer.testnet.evm.eosnetwork.com
• faucet.testnet.evm.eosnetwork.com
  • EOS Nation testnet faucet by @DenisCarriere
  • Also available at faucet.testnet.evm.eosnation.io

I delegated the testnet.evm.eosnetwork.com. subdomain to the TrustEVM AWS account. All infrastructure for the API, bridge, and explorer lives there. Each endpoint consists of a target group pointing at EC2 instances, a load balancer pointing at the target group, and a security group in front of the load balancer. A CNAME record points the subdomain at the load balancer. The API is in multiple regions, so a geographic routing policy was used to direct traffic to the region closest to a given client.

Mainnet

Endpoints and end-to-end network infrastructure were up for all three mainnet resources on 2023-04-07. Note there is no faucet for mainnet.

• api.evm.eosnetwork.com
  • Connect with MetaMask
  • Example using curl to get EOS-EVM mainnet block height:

    curl -fsSL 'https://api.evm.eosnetwork.com/v3' -X POST -H 'Content-Type: application/json' --data '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}' | jq .

• bridge.evm.eosnetwork.com
• explorer.evm.eosnetwork.com

I created a new AWS account for the mainnet endpoints from scratch including IAM policy documents, groups, roles, and users. I on-boarded my customers securely, delegated evm.eosnetwork.com. to this account, then stood up end-to-end network infrastructure for the mainnet endpoints. Each endpoint consists of a target group pointing at EC2 instances, a load balancer pointing at the target group, and a security group in front of the load balancer - same as the testnet endpoints. Unlike the testnet, I put an AWS Global Accelerator in front of each endpoint. This tooling ingests client traffic at their closest edge location and routes it over the AWS global fiber network to the closest healthy load balancer. This adds strong DDoS protection, global fail-over or fault tolerance, and geographic optimization. AWS claims this doubles throughput and halves latency according to independent testing.