Devconnect 2022 Amsterdam Day 1
Devconnect Amsterdam review day 1: ETH day
Hello everyone! Onther has decided to send some members to Devconnect 2022, which is happening in Amsterdam right now! We will share our personal experiences from these events using Medium, so stay subscribed for more news from us!
April 18th, 2022 was the first day of the Devconnect. Many developers and researchers worldwide gathered in Amsterdam to connect and share ideas about their passions and philosophy. This medium posting will summarize my day at Devconnect 2022 on the first day, and it will cover curated lists of the events that I attended.
Events covered in this posting:
- Launch of ETH day
- Welcome to Devconnect
- Ethereum 2.0 Roadmap
- What is new in ETHERSCAN
- Digging into DeFi
1. Launch of ETH day
The first event I attended at Devconnect week was ETH day. Eléonore Blanc of CryptoCanal started by welcoming the crowd with her warm energy. She was an outstanding organizer/host for the event and committed to opening up education to everyone.
CryptoCanal was founded in 2019 by Eléonore Blanc, offering education, events and consultancy services for the cryptocurrency industry. Hosting the Humans of Crypto Podcast, and running the CryptoCanal meetup in Amsterdam.
2. Welcome to Devconnect
The first speaker was Aya Miyaguchi, and she explained what Devconnect was about and explained why many of the sessions overlapped. She said that Devconnect is about “depth over breadth” (I cannot remember the exact phrasing). In other words, Devconnect sessions should encourage more in-depth discussions rather than overview types of discussions.
Devcon, which was delayed so many times, will be held in Bogata, Columbia, this year. Apparently, the team has been working on it to provide an excellent program for a long time.
She also reminded us that Ethereum foundation report had been published now.
3. Ethereum 2.0 Roadmap
The next talk was by Tim Beiko of AllCoreDevs. I have to say that his presentation was the highlight of the day. Tim started his presentation by explaining the changes to “Ethereum 2.0” Roadmap.
He explained that after the “merge” Ethereum client will be divided into Beacon Node, also known as the consensus layer, and Execution Engine/layer, which is responsible for processing blocks, maintaining mempools, and managing syncing state.
Post merge, the contents of a current ETH block will become an ExecutionPayload, part of the Beacon Chain blocks. Notably, the block time will change to exactly 12 seconds, minus skipped slots (<1% currently), several fields in block set are set to 0 because they are not needed (ommers, PoW), and Difficulty” OPcode will return “RANDOM” value.
Then, Tim gave an insight into how POS transition will actually happen:
First, the client will listen for TTD (Terminal Total Difficulty), which is the minimum triggering value for the merge. Once a block with TD (Total difficulty) equal to or bigger than TTD is detected, it will be deemed as the final PoW block, and validators will create any subsequent blocks on the Beacon Chain.
Once a post-TTD block has been finalized, clients will stop gossiping PoW block all together, wrapping up the “merge”.
In the above slide, you can see how the data from Execution layer (PoW) is moved to the Beacon chain at the post-merge blocks.
Tim also explained how the new Testnets are formed for POW-POS transition. Most notably, Kiln is the “Spec frozen” testnet launched in March 2022. The idea is that none of the specs (including the design) will change but more for applications and infra providers to test their product for bugs.
To test the “merge” in production, Shadow Forks are introduced to run in parallel to existing Ethereum networks. The idea is to start a small number of nodes with a low TTD and transition to POS on a new Beacon Chain. Then, txns from the main network are replayed on the shadow fork to test with real-world usage and test for stability.
Tim discussed how existing testnets and mainnet would be serviced after the shadow forks are consistently stable. Generally, new testnets are introduced to reduce the sync time for the storage used by the applications. Although you should not use testnets for your production applications, they provide meaningful ways to test out the applications before it is deployed to the real world; thus, the general consensus is not to break these testnets. One crucial point is that TTD might be hard to estimate in the mainnet due to difficulty bomb and declining hashrate. Although it will be hard to estimate the exact transition, the number 1 priority is the safety of Ethereum, and that should not be rushed.
Finally, Tim explained the limitations of the current way to introduce new Ethereum features and how they are implemented and publicized. EIP, also known as Ethereum improvement protocol, provides the change required. The yellow paper is official but math-heavy and often outdated.
So, it is up to the community to update the yellow paper whenever a new EIP is introduced, but this requires lots of work since EIPs are usually underspecified and the context of the change is underexplained.
To fix the current limitation, EELS is introduced. EELS: Ethereum execution layer specification consists of EIP to specify the high-level description of changes and executable specifications for EL & CK to specify the technical changes introduced. Obviously, this is a WIP and requires more time to mature.
4. What is new in ETHERSCAN
Harith Kamarul from Etherscan hosted the next event in the second stage (there were two stages in ETH day event). He first explained that ETHERSCAN has many features that are underappreciated and unknown to the community.
- Blockscan Chat: The first feature he thought was underused / underappreciated was Blockscan Chat. Although it isn’t decentralized, Blockscan Chat provides ethereum address holders to communicate with other by authenticating using ethereum signature.
2. NFT Page: NFT page shows variety of statistics of ERC-721 aka NFT token contracts.
3. Hide Spam Token Transaction: This third feature was probably the most interesting to me personally. As Ethereum is open and anyone can create tokens and send tokens to anyone, users can be easily spammed by weird token txns to their address.
This is a prevalent problem on Etherscan because users use Etherscan to monitor their account and txns that involves their accounts, and they do not want to comb through irrelevant txns (spams) to find relevant ones.
4. Double limits: I missed the explanation on this part. I will fill this at a later date.
5. Method Filter: this is a feature to filter out specific smart contract methods. It is a powerful visualization tool on etherscan to quickly check specific transactions.
6. Multichain explorer: Etherscan does provide developing blockchain explorer as a service as one of the ways to generate income. But, they will also start to provide general blockchain explorers for EVM based blockchains. This will be more relevant as rollups become more popular way to interact with Ethereum. Providing standardized general blockchain explorer also improves UX for users who are used to Etherscan products and improve security of the L2 network by providing a consistent experience to users.
5. Digging into DeFi
The last session I will cover is “Digging into DeFi” by Jermey Musighi from Balancer.
Jermey gave a short introduction on AMM discussing the evaluation of AMM and limitations of Uniswap in general: hard to customize.
He then briefly touched on the Balancer history. Balancer V1 was gas inefficient because users have to send/receive tokens from all pools. In V2, using Protocol vault, all tokens are transferred to/from the single vault, making it more gas efficient than V1.
More importantly Balancer V2 introduced the concept of “Cutomizable AMM logic”. This means that designing use-case specific AMMs with different trade-offs optimizing for different goals is possible:
- onSwap: determines # of tokens swapped (LP fee can be included in the logic)
- onJoinPool: Defines how many tokens need to be deposited
- onExitPool: How many tokens should the pool give
By customizing the aforementioned three parts of the Balancer AMM, it can be tailored to create a use-case specific AMM.
He then named and explained many custom AMM built based on Balancer 2.0 model. One of the most interesting use-case was AMM for index fund. It would be interesting to look into adopting Balancer AMM for Tokamak network.
Well, this wraps up the first day of Devconnect! It was a long day but an exciting one! Thank you for tuning in. And stay tuned for more updates from Devconnect Amsterdam 2022.
