devcon 6 / light client self led session
- YouTube
- IPFS
- Details
Light Client Self Led Session
Duration: 00:54:13
Speaker: Alex Stokes
Type: Workshop
Expertise: Intermediate
Event: Devcon
Date: Oct 2022
tbd
Categories
- Related
Devcon
Talk
24:53
Ethereum in 25 Minutes, Version MMXVII
So what are all of the different moving parts of the Ethereum blockchain? What are uncles, how do contracts call other contracts, who runs them? What is the role of proof of work and proof of stake, and what exactly is gas? What will EIP86 do for you? Vitalik Buterin provides a 25-minute technical overview of the ethereum blockchain, start to finish, and explain many of these concepts in detail.
Devcon
Talk
23:52
Ethereum for Dummies
Ethereum's CTO Dr. Gavin Wood presents "Ethereum for Dummies" or "So, now we've built it, WTF is it?"
Devcon
Talk
38:18
Understanding the Ethereum Blockchain Protocol
Ethereum's Vitalik Buterin presents on the intricacies of the Ethereum Blockchain Protocol.
Devcon
Breakout
19:31
Yul, eWasm, Solidity: Progress and Future Plans
Over the last months, the Yul language has matured and proved its flexibility. The Solidity team has implemented an optimizer and an eWasm dialect and is now full steam working on rewriting the Solidity code generator to produce Yul code to replace sequences of EVM instructions.The Yul optimizer now matches the old EVM optimizer and already surpasses it with features like function inlining and cross-function optimization. This is also the main reason why the new code generator can be written in a super-modular way. Furthermore, it can equally operate on EVM- and eWasm-flavoured Yul code, which is important to cope with the 256- to 64-bit translation.Through this, the Solidity compiler can now output eWasm code, which makes efficient use of 64 bit types. Furthermore, the new code generator includes automated overflow checks everywhere, again something that would have destroyed the old optimizer. Future work:We plan to use a more intricate formal system to remove redundant operations and checks based on range-relations between variables. The introduction of memory area types will help optimizing memory allocation. Finally, a super-optimizer could prove useful, since it is worth spending extra time on compilation to save gas.
![Keynote: [title redacted] preview](https://img.youtube.com/vi/lRqnFrqpq4k/maxresdefault.jpg)
Devcon
Talk
26:22
Keynote: [title redacted]
[description redacted]
Devcon
Talk
26:47
Exploring the Future of Account Abstraction
Discover the journey of Ethereum's Account Abstraction (AA) from inception to its current state, challenges tackled by ERC-4337, and future roadmap: modular native AA approach for L2 and L1, and EOA improvement (EIP-7702).
Devcon
Talk
12:09
Improving the federated 2-way peg: A new sidechain design for trustless bridges on Ethereum
In this talk, we'll introduce a novel mechanism to maintain 2-way pegs, as well an initial implementation of a Bitcoin peg on Ethereum. ## Problem Bitcoin's stable codebase is a strength. Developers are loathe to introduce significant changes, reasoning that a store of value should prioritize stable operation. While this cemented Bitcoin's place in the market, we all know the costs- Bitcoin's ossification at the expense of public experimentation and diverse use cases. In 2014, the answer to this problem was "sidechains". Trustless sidechains are the ultimate vaporware- and since 2014 the goalposts have moved. ## Approaches Blockstream's Liquid touted itself as the "first production sidechain", built on a multi-sig federation. No hashpower validates the sidechain-- funds are fully trusted to 15 Bitcoin multi-sig participants. BitGo's WBTC takes a similar tact-- but instead of building a new chain, custodians operate on Ethereum. Neat! Unfortunately, they require KYC :( These centralized projects have a few custodians that can be convinced by governments-- or their own interests-- to censor or seize funds. ## Design We propose a new approach-- the *bonded, multi-federated peg*. We believe this is the best candidate for a sufficiently trust-minimized alternative, unlocking Bitcoin for use in DeFi.
Devcon
Breakout
20:25
Overcoming the smart contract size limit
EIP 170 introduced a limit of 24KB on bytecode size of smart contracts in Ethereum. This talk will explain the rationale behind the decision and then talk about overcoming or playing around the limit. The talk will cover ways like proxy patterns and libraries for working around the limit. Tips on optimizing code for reducing bytecode size will also be shared. The talk will then explain new proposals for removing the contract size limit while still fixing the original problem.
Devcon
Talk
22:13
Guidance on Assessing a Blockchain Platform
Blockchain platforms are maturing to enable decentralized architecture but vary in design depending on deployment environments, such as open digital ecosystems or contained multiparty environments. In this session we provide a summary of Gartner's observations on blockchain platforms adoption, a functional framework for assessing blockchain platforms, and future projections on blockchain platforms technical evolution.
Devcon
Talk
22:13
Securing Layer 2 Networks with Ethereum, Decentralized Storage, and Shared Fishermen
Running data-intensive applications on top of existing blockchain platforms remains a challenge. Modern blockchains are designed for maximum security and have limited compute and storage capacity, which means they are too expensive to handle nontrivial amounts of data. However, traditional applications often need high transaction throughput and low latency of request processing. I will show how to address the scalability and cost efficiency requirements with a hybrid architecture composed of several layers. Speed layer consists of real-time shards directly talking to a client; security layer provides finality and consists of fishermen verifying past speed layer behavior; dispute resolution is served by the Ethereum smart contract; finally, decentralized storage networks such as Swarm or IPFS provide data availability. In this talk, we will go through the hybrid architecture approach and explore how it can make the cost of running a classical database (e.g., Redis or SQLite) in the decentralized environment comparable to its centralized deployments without compromising security.