Steps for developer community during hard work, Mainly focuses on Infura

1. INFURA IN POST
FORK WORLD

2. • OVERVIEW INFURA ARCHITECTURE
• INFURA IN POST FORK WORLD
• HOW TO ENSURE MINIMUM DOWNTIME
• EFFORTS REQUIRED FROM DEVELOPER COMMUNITY
TO ENSURE SMOOTH TRANSITION TO UPGRADED
CLIENTS
AGENDA

3. INFURA provides
secure, stable, fault
tolerant and scalable
Ethereum
and IPFS nodes.

4. INFURA BOOMERANG ARCHITECTURE

5. INFURA
• Leveraging Microsoft Azure to maintain global peers which ensures
that our core endpoints are only a few hops away from the nodes on
rest of the network
• INFURA supports a subset of Ethereum’s JSON-RPC methods. Most of
the unsupported methods have to do with private keys
• Caching, early-warning monitoring and auto-routing to healthy nodes
and rich analytics
• For example it uses SQL for logging and redis for catching to handle
certain requests like block number which doesn’t change for 10-15
secs

6. INFURA FEATURES
• Public HTTPS enabled endpoints for ethereum mainnet
and testenets
• Portable interface—fully compatible with the standard
JSON-RPC API including the popular web3.js, ethjs
JavaScript libraries; Java, Python etc
• Multi-client Ethereum backend with most popular clients
Geth and Parity
• Public HTTPS-enabled IPFS gateway for decentralized
storage
• Can be used to create private clusters

7. INFURA FEATURES
• Acts as zero client gateway service to access ethereum
network, runs on node using JavaScript code of the
user
• No need to wait to sync the entire chain data and no
installations required
• Minimal hardware requirements, for example
Metamask which runs as a browser plugin and
connects to Ethereum Blockchain

8. Byzantium Hard Fork
• Upgrade will introduce nine key improvements to the
platform
• Upgrade is designed to make the platform lighter and faster
to run, improve the transaction speed, smart contract
security and privacy
• The hard fork will be implemented at block number
4,370,000
• In a post-fork world, if you are running your own Ethereum
node you will want to be sure you are participating on the
blockchain that you intend to be.

9. Byzantium Hard Fork
• To make sure you are on the right chain upgrade your
Ethereum clients by block number 4,370,000.
• It is advised to resync the entire chain after upgrading
the client to make sure you are on the right chain
• The two of the most popular client versions that you
need to be running after the fork are
1) Geth 1.7.2
2) Parity 1.7.6

10. INFURA POST FORK
• Post fork, we at INFURA need to make sure that all our
nodes are on the right chain
• We need to ensure that client version we are using are
upgraded post fork and chain data synced properly
• It boils down to Geth vs parity sync time to resume services
post fork
• Parity has better block processing speed than Geth

11. INFURA POST FORK
• Parity uses snapshots to quickly get a full copy of the state
at a given block. Every 30,000 blocks, nodes will take a
consensus-critical snapshot of that block's state. Any node
can fetch these snapshots over the network, enabling a
fast sync
• Parity is the fastest and lightest Ethereum block
processing engine amongst the available clients
• Parity with - - warp sync flag is faster than Geth --fast
when trying to sync the whole chain data

12. INFURA POST FORK
• Routing the traffic to fully synced Ethereum nodes to ensure
the participation on the right chain
• Planning the client update as soon as the hard fork occurs to
ensure minimum downtime
• Using the chain data from a fully synced directory to initialize
other nodes
• Routing the requests to parity after the fork as it is faster to
sync and resuming the normal services with both Geth and
parity

13. DEVELOPERS USING INFURA AS BACKEND
• Prepare your project websites and mail your users
regarding the hard fork and downtime
• Make sure your clients are upgraded to latest version if
you are using local nodes for peering
• Reach out if you have any further questions or issues
regarding the upcoming Byzantium hard fork and
Infura

14. QUESTIONS?